Proposal: [301] 16-bit memory access

Informal

This page is dedicated to discussing this specific proposal

ContributeContributions

StephenPelcavatar of StephenPelc [301] 16-bit memory accessProposal2023-06-19 13:36:15

Authors

Stephen Pelc, stephen@vfxforth.com Leon Wagner, leon@forth.com

Change Log

19 June 2023, First release

Problem

16-bit data items are often required, e.g. for networks, for input and output, and for operating system data structures. Words to fetch and store data of this size are not yet standardised.

Solution

The words W@,W! and W, are in common use.

Proposal

6.1.xxxx W@ w-fetch CORE ( w-addr -- w16 )

Fetch the 16-bit item stored at w-addr. When the cell size is greater than 16 bits, the unused high-order bits are all zeroes.

See: 3.3.3.1 Address alignment.

6.1.xxx W! w-store CORE ( w16 w-addr -- )

Store a 16-bit item at w-addr. When a 16-bit item is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

See: 3.3.3.1 Address alignment.

6.1.xxx W, c-comma CORE ( w16 -- )

Reserve space for one 16-bit item in the data space and store w16 in the space. If the data-space pointer is 16-bit aligned when W, begins execution, it will remain 16-bit aligned when W, finishes execution. An ambiguous condition exists if the data-space pointer is not 16-bit aligned prior to execution of W,.

See: 3.3.3.1 Address alignment.

Rationale

The majority of new Forth systems developed in the 21st century use 32-bit or 64-bit cells. This proposal covers 16-bit memory access operators for such systems.

Reference Implementation

These words are hardware and implementation dependent.

AntonErtlavatar of AntonErtl

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.

rcfg7943avatar of rcfg7943

If there are any alignment requirements of any kind, wouldn't that defeat the purpose of these words?

rcfg7943avatar of rcfg7943

Please add a similar proposal for 64-bit equivalents. Thank you.

Rodavatar of Rod

6.1.xxx W, c-comma CORE ( w16 -- ) Should read w-comma

Reply New Version