llvm dev - Oct 2012 - [LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes

On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
>
> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at
ericsson.com> wrote:
>
>>> non-8-bit byte
>
> I'm a bit confused by this concept. I'm aware of the archaic
meaning of the word byte, but it has meant 8 bits for the last 30 years.
There's even an ISO/IEC standard.
>
> I know of architectures like Texas' C55x DSPs that address 16 bits at a
time, but even their data sheets state:
>
> • 256K Bytes Zero-Wait State On-Chip RAM, Composed of:
>   • –  64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit
>   • –  192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit
>
> Perhaps you could begin by defining more accurately what you're talking
about?
I'm assuming he means an architecture where CHAR_BIT > 8.

-Eli

On Oct 19, 2012, at 10:47 AM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
>> 
>> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at
ericsson.com> wrote:
>> 
>>>> non-8-bit byte
>> 
>> I'm a bit confused by this concept. I'm aware of the archaic
meaning of the word byte, but it has meant 8 bits for the last 30 years.
There's even an ISO/IEC standard.
>> 
>> I know of architectures like Texas' C55x DSPs that address 16 bits
at a time, but even their data sheets state:
>> 
>> • 256K Bytes Zero-Wait State On-Chip RAM, Composed of:
>>  • –  64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit
>>  • –  192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit
>> 
>> Perhaps you could begin by defining more accurately what you're
talking about?
> 
> I'm assuming he means an architecture where CHAR_BIT > 8.
AFAIK, CHAR_BIT isn't a property of the architecture, but of the C
implementation.  One can imagine having two different (non-ABI-compatible) C
implementations for the same ISA that define CHAR_BIT differently.

--Owen

On Fri, Oct 19, 2012 at 11:04 AM, Owen Anderson <resistor at mac.com>
wrote:
>
> On Oct 19, 2012, at 10:47 AM, Eli Friedman <eli.friedman at
gmail.com> wrote:
>
>> On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
>>>
>>> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H
<patrik.h.hagglund at ericsson.com> wrote:
>>>
>>>>> non-8-bit byte
>>>
>>> I'm a bit confused by this concept. I'm aware of the
archaic meaning of the word byte, but it has meant 8 bits for the last 30 years.
There's even an ISO/IEC standard.
>>>
>>> I know of architectures like Texas' C55x DSPs that address 16
bits at a time, but even their data sheets state:
>>>
>>> • 256K Bytes Zero-Wait State On-Chip RAM, Composed of:
>>>  • –  64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit
>>>  • –  192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x
16-Bit
>>>
>>> Perhaps you could begin by defining more accurately what you're
talking about?
>>
>> I'm assuming he means an architecture where CHAR_BIT > 8.
>
> AFAIK, CHAR_BIT isn't a property of the architecture, but of the C
implementation.  One can imagine having two different (non-ABI-compatible) C
implementations for the same ISA that define CHAR_BIT differently.
Fine, then a *target* where  CHAR_BIT > 8.

-Eli