Digest #227 2023-07-08
Contributions
I am thinking about (maybe proposing) language implementation standards for Forth language classifications, such as:
- FDI: Forth Dictionary Implementation; a minimum percentage of Forth words implemented by the language.
- FPI: Forth Paradigm Implementation; some minimal Forth type bootstrapping from a host language or chip instruction set.
- FOL: Forth Like; resembles Forth, but not FDI and not FPI.
- FLI: Forth Language Implementation; is both FDI and FPI.
Such taxonomy could assist programming language developers in their planning/goals, while giving new users of a "Forth" an immediate indication of its limits and potential.
My apologies if I missed prior communiques related to this subject, or if another Forth forum is better suited to this discussion.
Replies
This proposal does not define what a "w-addr" is. It references the "Address alignment" section, but is not clear about the alignment requirements. I assume that you intend a w-addr to be 16-bit aligned. This proposal also does not define "w16". Given that you zero-extend the value, you can just write "u" instead.
In Gforth, w@, w!, l@, l! etc. all have no alignment requirements (expressed by using "c-addr"). This means that their implementations on some architectures are slower, but OTOH it means that we don't need to add words like w@u, w!u etc. for unaligned access.
These words don't address byte order and signed values. Gforth also has words for that, see Special Memory Accesses.
Proposal author here. Apologises for my slow reply. I've been trying to reset the password to my account but it appears there is no way to do so. I've even tried contacting the site administrator via various email addresses that appear to be associated to this website but I receive no reply. Hence, the new account. If anyone can delete my old user 'sxjh9935', please do.
@MitraArdron and @AntonErtl
Since posting my proposal, I've notice two other more recent proposals(i.e. 301 and 302) and it appears they address my needs and may be more consistent with current practices.
Given such, I think it is appropriate if this proposal is withdrawn in lieu of those more recent proposals.
But for the sake of completeness, I will address your questions.
@MitraArdron I am assuming that the cell have a width of 32-bits.
This allows 2! and 2@ for on 64-bit values, ! and @ for 32-bit values and C! and C@ for 8 bit values.
However, I appreciate this may create problems if the cell width was anything other than 32-bits. For example, if the cell width was 64-bits. If the cell width was 64-bits, you could probably address the issue using the 2C@/2C! words as proposed or C@/C! but then why wouldn't I just use the C@/C! in lieu of these words. Perhaps having words independent of the cell width (as per the aforementioned more recent proposals) will avoid this problem.
Fortunately @ and !, 2@ and 2! aren't dangerous in my circumstances but thank you for the concern. The implementation and operating system I'm working with is written largely in Forth and I'm very familiar with the implementation of the aforementioned words. I had raised this proposal because 16-bit words were required for the network driver and network stack implemented and I was surprised that something did not already exist in the published standards.
@AntonErtl
Thank you for pointing out these words. I wasn't aware of them. I hope these words and other related words are standardised within the CORE dictionary/library in the near future. I also note that they are the subject of the more recent proposals mentioned herein.
If there are any alignment requirements of any kind, wouldn't that defeat the purpose of these words?
Please add a similar proposal for 64-bit equivalents. Thank you.
6.1.xxx W, c-comma CORE ( w16 -- ) Should read w-comma
Yes, AFAICS your contribution is not quite on-topic, as this website is about the Forth-2012 standard and it's successors. So if there is enough interest in your ideas, you should look for another place (or maybe a separate part of this website, but you would have to discuss this with Gerald Wodni) for more involved discussions and development.
There have been several proposals for a minimal-Forth standard over the years, with some interest expressed by others, but none that led to a significant development of a standards document. It seems to me that many of those who develop small Forth systems are happy with using their own system-specific subset of Forth-2012, if they are interested in a standard at all (but interestingly, even some who write anti-standard rethoric use the standard in some cases). But who knows, maybe your ideas will be the ones that gain a critical mass.