Read a byte (octet) from memory

[ruv]

There is a new proposal at forth-standard.org: Special memory access words.

This made me wonder what words people use to read a byte (of 8 bits) from memory.

If in your application you need to read exactly one byte (octet) at an address, which word do you use (or are likely to use): c@ ( addr -- x ) or b@ ( addr -- x )? Or something else?

[cwpjr]

Since we have evolved from 8bit computing I would '*user test' this vernacular: 1bit@ 8bit@ 16bit@ 32bit@ 64bit@ 128bit@; I have accessed memory in my forths up to that last (128) bit size. 'see' how it feels to you and let me know please

…

On Mon, Jun 24, 2024 at 11:12 AM ruv ***@***.***> wrote: There is a new proposal at forth-standard.org: Special memory access words <https://forth-standard.org/proposals/special-memory-access-words#contribution-343> . This made me wonder what words people use to read a byte (of 8 bits) from memory. If in your application you need to read exactly one byte (octet) at an address, which word do you use (or are likely to use): c@ ( addr -- x ) or b@ ( addr -- x )? Or something else? — Reply to this email directly, view it on GitHub <#158>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABILVRIGI2AU4YTGJKGLQ3DZJBAN3AVCNFSM6AAAAABJ2EF7PKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWHA2TQOBSGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[CCurl]

On my systems:

C@ 8 bits
W@ 16 bits
L@ 32 bits
@ 32 or 64 bits depending on target system

[ruv]

I would 'user test' this vernacular: 1bit@ 8bit@ 16bit@ 32bit@ 64bit@ 128bit@;

What is the stack diagram for 1bit@ and 128bit@? And what about endianness and sign extension?

Otherwise, these names are somewhat acceptable to me, but I prefer a form that does not start with a digit.

Possible variants:

• uint8@ uint16@ uint32@ uint64@ uint128@
• u8@ u16@ u32@ u64@ u128@

[cwpjr]

Evolution of c@ is easy enough to read and understand, yet wouldn't 64 = 2L?

…

On Mon, Jun 24, 2024 at 7:25 PM Chris Curl ***@***.***> wrote: C@ 8 bits W@ 16 bits L@ 32 bits @ 32 or 64 bits depending on target system — Reply to this email directly, view it on GitHub <#158 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABILVROCYXS5YL45WUH4YF3ZJC2G3AVCNFSM6AAAAABJ2EF7PKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNRVGY2DM> . You are receiving this because you commented.Message ID: ***@***.***>

[ruv]

@cwpjr writes:

Evolution of c@ is easy enough to read and understand,

If I write in my program c@ or c!, it usually means that the actual size in bits does not matter for this program. So I prefer to write b@ or b@ to emphasize that the size of the data object is exactly 8 bits, and it is important for the program.

yet wouldn't 64 = 2L?

In the standard word name 2@ ( a-addr -- 2*x ), 2 means the size of the data object in cells on the stack.

From this point of view, the standard word name @ ( a-addr -- x ) is a shortcut for 1@ ( a-addr -- 1*x ).

Thus, if we have the word L@ ( addr -- x32 ), then the word 2L@ must have the stack diagram ( addr -- x32.a1 x32.a0 ), and the stack parameter x32.a0 must be located at addr (similar to the word 2@).

---

Regarding the stack notation. The notation i*x means a tuple of any single-cell items. 2*x means two items, so ( 2*x ) is equivalent to ( x x ) — a cell-pair, where x is a symbol for "unspecified cell" (see 2.2.2 Stack notation, and Table 3.1: Data types).

[cwpjr]

This is why I propose words - to see the response of this community. I agree RUV, your words are 'better', tho I have no aversion to words starting with digits, so far~! sint8@ so what about endianess? How is this evolution? LE_sint8@ BE_sint8@

…

On Tue, Jun 25, 2024 at 7:55 AM ruv ***@***.***> wrote: I would '*user test*' this vernacular: 1bit@ 8bit@ 16bit@ 32bit@ 64bit@ 128bit@; What is the stack diagram for 1bit@ and 128bit@? And what about endianness and sign extension? Otherwise, these names are somewhat acceptable to me, but I prefer a form that does not start with a digit. Possible variants: - uint8@ uint16@ uint32@ uint64@ uint128@ - u8@ u16@ u32@ u64@ u128@ — Reply to this email directly, view it on GitHub <#158 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABILVRIICOM6NIFW3ZTJTFTZJFSC3AVCNFSM6AAAAABJ2EF7PKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNZRGQYDI> . You are receiving this because you commented.Message ID: ***@***.***>

[MitchBradley]

Open Firmware, which was standardized as IEEE1275-1994 (approximately concurrently with ANS-FORTH) and subsequently deployed on millions of computers, has a comprehensive solution. The size prefixes are B, W, L, and X for 8,16,32, and 64. Those can be further prefixed with BE-, LE-, and REG- for big-endian, little-endian, and hardware register access. Prepend < for sign extension.

The Forth community is famous for not knowing its history and reinventing the same wheel "OVER AND OVER AND OVER AGAIN" - which could be a Forth program if you prepend BEGIN.

[ruv]

@MitchBradley writes:

Open Firmware, which was standardized as IEEE1275-1994 (approximately concurrently with ANS-FORTH) and subsequently deployed on millions of computers, has a comprehensive solution. The size prefixes are B, W, L, and X for 8,16,32, and 64. Those can be further prefixed with BE-, LE-, and REG- for big-endian, little-endian, and hardware register access. Prepend < for sign extension.

This approach is known and considered in the current proposals. Personally, this approach is acceptable to me, except the names that start with <, like <BE-W@ (I would prefer something like BE-SW@).

This approach produces a set of 24 words: | {<, } × {BE-, LE-} × {B, W, L, X} × {@ } + {BE-, LE-} × {B, W, L, X} × {! } | = 2 * 2 * 4 * 1 + 2 * 4 * 1 = 16 + 8 = 24 words (don't take into account registers, only memory).

[update] There is a mistake. BE and LE are not needed to read/write a byte. See in my other message bellow.

There is an alternative approach, where the functionality of these words is disjoint to read/write, change order, extend sign.

It produces a set of 18 words: | {B, W, L, X} × {@, !} + {W, L, X} ×{ BE, LE } + {B, W, L, X} ×{ >S } | = 4 * 2 + 3 * 2 + 4 * 1 = 8 + 6 + 4 = 18 words.

The different is: 24 - 18 = 6 words.

Both approaches assume that an address unit size is 8 bits.

The phrases in the first approach:

BE-W@
BE-SW@

BE-W!

are written in the second approach as:

W@ WBE
W@ WBE W>S

WBE W!

I tend to favor an approach that requires standardizing fewer words. But I'm not sure yet.

[ruv]

I tend to favor an approach that requires standardizing fewer words. But I'm not sure yet.

If we want fewer words, we can introduce only 4 words, for example: B( , W(, L(, and X(, which parses their immediate arguments till ")" and produce (or execute) the appropriate code. But the specifications for these words will be more complex.

In this approach the above examples can (as a variant) be written as:

W( BE @ )
W( BE S @ )

W( BE ! )

Where BE ( -- ) and S ( -- ) are mode switches.

It's also possible to implement it even via a single word, like:

MEM( W BE @ )
MEM( W BE S @ )

MEM( W BE ! )

[ruv]

The different is: 24 - 18 = 6 words.

There is a mistake. Different endianness is not needed to read/write a byte.

The corrected variant. The first approach produces a set of 21 words:
| {<, } × {BE-, LE-} × {W, L, X} × {@ } + {BE-, LE-} × { W, L, X} × {! } + {<, } × {B } × {@} + {B } × { ! } |
= 2 * 2 * 3 * 1 + 2 * 3 * 1 + 2 * 1 * 1 + 1 * 1 = 12 + 6 + 2 + 1 = 21 words.

The difference is: 21 - 18 = 3 words.

If we need to read/write fixed-width units in the Forth-system native endianness, it adds: 2*3 + 3 = 9 words in the first approach, and nothing in the second approach. The different will be 3 + 9 = 12 words.

[MitchBradley]

Don't forget alignment. When you are unpacking an externally-defined data packet, the fields might not be aligned suitably for hardware fetch/store instructions, either because they are packed wrong or because the start of the packet is not strongly-aligned. For this reason, Open Firmware specified that the BE- and LE- words must be implemented so they would not cause hardware exceptions due to alignment. Byte-swizzling-after-native-access often fails on aligned hardware. Exceptions due to accessing non-existent memory is okay.

The opposite was true for the REG- words, since hardware registers often require a specific access width.

Saving a few words at the expense of making programmers work harder is often not the right tradeoff.

[ruv]

Don't forget alignment.

Yes, the proposal [343] Special memory access words explicitly declares that address alignment is not required for these words.

[cwpjr]

Thanks Mitch. I admire the work you have done to get us here. My interest is at the root of Forth, yet extending or swapping the "machine primitives" is a intellectual foray into vernaculars for domains, and as such are just conjectures and musing on the side of the pre existing Forth systems and Standards. Weather than being ignorant or lacking in domain research or expertise I feel fine with this discussion, and appreciate your input. Let's not be little committees squabbling about the conferderates outside in the hallways please.

…

On Tue, Jun 25, 2024 at 10:52 AM Mitch Bradley ***@***.***> wrote: Open Firmware, which was standardized as IEEE1275-1994 (approximately concurrently with ANS-FORTH) and subsequently deployed on millions of computers, has a comprehensive solution. The size prefixes are B, W, L, and X for 8,16,32, and 64. Those can be further prefixed with BE-, LE-, and REG- for big-endian, little-endian, and hardware register access. Prepend < for sign extension. The Forth community is famous for not knowing its history and reinventing the same wheel "OVER AND OVER AND OVER AGAIN" - which could be a Forth program if you prepend BEGIN. — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABILVRPEIWCZONDWOXDV353ZJGG2FAVCNFSM6AAAAABJ2EF7PKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNZTGMZDC> . You are receiving this because you commented.Message ID: ***@***.***>

[cwpjr]

Thank you for the clarification. I also apologize as I did not consider this thread as inside the committee doors. I will ask the first question first from now on. Tx for the ascii.

…

On Tue, Jun 25, 2024 at 12:54 PM ruv ***@***.***> wrote: The different is: 24 - 18 = 6 words. There is a mistake. Different endianness is not needed to read/write a byte. *The corrected variant.* The first approach produces a set of *21 words*: | {<, } × {BE-, LE-} × {W, L, X} × {@ } + {BE-, LE-} × { W, L, X} × {! } + {<, } × {B } × {@} + {B } × { ! } | = 2 * 2 * 3 * 1 + 2 * 3 * 1 + 2 * 1 * 1 + 1 * 1 = 12 + 6 + 2 + 1 = 21 words. The difference is: 21 - 18 = 3 words. If we need to read/write fixed-width units in the Forth-system native endianness, it adds: 2*3 + 3 = 9 words in the first approach, and nothing in the second approach. The different will be 3 + 9 = *12 words*. — Reply to this email directly, view it on GitHub <#158 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABILVRJRMGS6FSZUXBHOFM3ZJGVFDAVCNFSM6AAAAABJ2EF7PKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNZUGQ2TG> . You are receiving this because you were mentioned.Message ID: ***@***.***>