Path: csiph.com!usenet.pasdenom.info!gegeweb.org!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.programming
Subject: Re: 64-bit bytes
Date: Mon, 12 Jan 2015 21:05:43 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 52
Message-ID: <20150112125154.237@kylheku.com>
References: <1d1b426e-452d-43ac-a15d-31dff9833370@googlegroups.com> <a19e7c48-06e8-4b66-8faf-e7f4b92af0a9@googlegroups.com> <442bffa5-0e87-4924-a8e2-19dc69236183@googlegroups.com> <07379e64-43df-4e01-9506-fee7d5f56c80@googlegroups.com> <GCEsw.973563$CW3.557830@fx07.am4> <GxFsw.532620$td3.314128@fx34.am4> <y9Msw.578728$RM2.35041@fx43.am4>
NNTP-Posting-Host: X+c6YNb3AaWMPA3YfA4opg.user.speranza.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.programming:5121

On 2015-01-12, Richard Heathfield <invalid@see.sig.invalid> wrote:
> BartC wrote:
>
>> On 12/01/2015 00:32, Richard Heathfield wrote:
>>> robin.vowels@gmail.com wrote:
>>>
>>> <snip>
>>>
>>>> A byte is a fixed-length field of 8 bits.
>>>
>>> ...except when it isn't. For example, some embedded systems
>>> ("freestanding implementations") use 32-bit bytes. At least one of the
>>> Analog SHARC chips uses 32-bit bytes.
>>>
>>> IEC 80000-13 defines the byte to be 8 bits, but there are other
>>> international standards that use more flexible definitions (e.g. ISO/IEC
>>> 9899, which requires only that a byte must be *at least* 8 bits).
>> 
>> Nonsense.
>
> Nonsense it may be. ISO/IEC 9899 it most certainly is.

Nobody but a few C language lawyers care that ISO 9899:XXXX defines "byte"
as corresponding to "char", which means that on some compilers, byte
refers to something that has 16 or 32 bits.

I actually from time to time maintain a code base, part of which is
compiled with such a compiler. Part of the code base runs on a DSP chip
block, and another part of the code base runs on the main host core,
communicating with the DSP using a kind of remote procedure call. They share
binary data such as structs, so things are carefully declared. When sizes are
passed, you have to be clear: is that the size in 16 bit units or 8 bit units?

Guess what: throughout the code, 8 bit units are called ... bytes. In all
function interfaces, "length in bytes" of an object means exactly twice of the
"sizeof" that object on the DSP side. Macros are used: SIZEOF_B and SIZEOF_W.
These macros do the right thing whether they are compiled on the DSP or the
host.  On the DSP, SIZEOF_W is just sizeof, and SIZEOF_B has to multiply by
two.  On the host, SIZEOF_W divides by two, rounding up, and SIZEOF_B is
native.

I.e. when you're actually working with systems like this is when you're
most likely to cause confusion by insisting on the ISO9899 terminology,
because you have multiple compilers and none agree on what a byte is.

It's easier to just call those things "char", and have them disagree on
what a char is, and use the term "byte" consistently.

The underlying hardware is a unified SoC. Parts of that chip know what
a byte is and can address it (like the host ARM core). It behooves that
unit to be called a byte, even if there is a DSP block on the same
internal bus which cannot address such a unit.