New datatype addition to gcc
Tue Dec 14 14:07:00 GMT 2004
Eljay Love-Jensen wrote:
> Hi Sriharsha,
> Is the architecture truly 16-bit addressing? That is to say, a byte
> is 16-bit; address location 0x0100 is 16-bits away from address
> 0x0101? Then you'd want (must have!) char to be 16-bit, of course.
Yes, its truly a 16-bit architecture. i.e. 0x1000 is 16-bits away from
> The "short char" (octet) would be an optimization, and you wouldn't be
> able to take the address of one -- so it would be a second class data
> type at best.
> Would you want a string (e.g., "Hello world") to take up 12 bytes (24
> octets), or to take up 6 bytes (12 octets)? Or maybe something like
> S"Hello world" to pack a string into octets, the S stands for
> something like "short char". (I've seen something like that for
> InfoCom games that used 5-bit "packed characters" in their Z-engine.)
We would want the string to take (if specified by programmer or under
certain conditions*) 6 bytes (12 octets). The special conditions can be
something as follows:
Whenever a variable is declared of this special type (typically used in
Network programming where framing and de-framing packets byte-by-byte
(12 octets) is required. This is _ONLY_ needed for READ/STORE
operations. Arithmetic is _NOT_ required.
> Could the new instructions be taken advantage of by doing a
> combination of S"ShortChar string" and:
> struct ShortChar
> char first : 8;
> char second : 8;
This idea is quite good, but I dont understand the whole point. They
dont want structures defined like this. Ofcourse, if something like this
should exist in the code, then it would be preferable that the compiler
uses the new instructions (READ/STORE 8-bit Data) to read/store them.
> And then let the optimizer use the new instructions to access first
> and second elements of a ShortChar?
I Guess so.
> As far as implementation in GCC... that's beyond my expertise. :-)
Any one else??
Thanks a Lot,
More information about the Gcc-help