The following scenarios are relevant to determining the definition of system types ...
Before architectures will move to multiple-of-8-bit bytes, it is likely that prior to such change there would have been a shift in a number of programming languages using larger "virtual" bytes and the common use of the term "byte" itself might have changed to mean a larger unit than 8 bits. At that point there would be 8-bit machine-bytes and multiple-of-8-bit software bytes.
If and when architectures will move to multiple-of-8-bit bytes, it is likely that even after such change there would still remain architectures and languages using 8-bit bytes. At that point there would be a need for a backwards compatible 8-bit byte in languages that mandate a de-facto 8-bit byte and languages that have a large code base that depends on de-facto 8-bit bytes, e.g. C and C++.
Legacy computer systems with 18 and 36-bit words are still in use, although their significance and numbers are in decline and they will eventually disappear. When compilers for languages that mandate 8-bit bytes or de-facto 8-bit bytes are targeted at architectures that use bytes wider than eight bits but not multiple's of eight bits, a common technique is to ignore the extra bits and use mappings whereby the number of wasted bits is minimal. This approach does not usually incur any significant performance penalty.
Embedded micro-controllers with 4-bit wide bytes continue to be developed, manufactured and used in large numbers. When compilers for languages that mandate 8-bit bytes or de-facto 8-bit bytes are targeted at architectures that use bytes with significantly less than eight bits, there are two possible approaches. One approach is to simulate an 8-bit architecture by combining multiple smaller-than-8-bit bytes into a single 8-bit byte. This approach is extremely inefficient and generally unsuitable for embedded micro-controller development. The other approach is to add an additional non-standard machine byte that matches the size of the actual architecture. This approach is efficient but it renders the source code non-standard.
A new type OCTET
shall be introduced
BYTE
and LOC
in all occurrences of the standard library
It remains to be determined whether OCTET
should be
SYSTEM
Type BYTE
shall remain
OctetsPerByte
shall define the number of bytes per word
SYSTEM
Type WORD
shall remain
BytesPerWord
shall define the number of bytes per word
SYSTEM
A new type MACHINEBYTE
shall be introduced
BitsPerMachineByte
shall define the number of bits per machine byte
SYSTEM
MACHINEBYTE
shall be implementation defined
For 8-bit byte target architectures, BitsPerMachineByte
shall have a value of 8
and type MACHINEBYTE
shall be an alias for OCTET
. For non-8-bit targets, implementors shall be at liberty to implement the target by emulating an 8-bit byte architecture and if they do so, BitsPerMachineByte
shall have a value of 8
and type MACHINEBYTE
shall be an alias for OCTET
.
A new type MACHINEWORD
shall be introduced
MachineBytesPerMachineWord
shall define the number of machine bytes per machine word
SYSTEM
MACHINEWORD
shall be implementation defined
For 8-bit byte target architectures, MachineBytesPerMachineWord
shall have a value identical to BytesPerWord
and type MACHINEWORD
shall be an alias for WORD
. For non-8-bit targets, implementors shall be at liberty to implement the target by emulating an 8-bit byte architecture and if they do so, MachineBytesPerMachineWord
shall have a value identical to BytesPerWord
and type MACHINEWORD
shall be an alias for WORD
.
Type ADDRESS
shall remain
OctetsPerAddress
shall define the number of octets required to store an address
MachineBytesPerAddress
shall define the number of machine bytes per address
SYSTEM