New datatype addition to gcc

New datatype addition to gcc

[Sriharsha Vedurmudi]

Hello All,

	I want to know if it is feasible (without too much of work) to add a new custom data-type to gcc 3.2.

We have a processor which originally has 16-bit addressing. So, while porting gcc3.2 to our processor, modifications were done to the effect 
that even character datatypes will access/address 16- bits. Now, our Processor development team says, they are adding 4 new instructions 
(load/store lo/high byte) and they want for the compiler to provide a provision where 8-bit addressing is possible in parallel with 16-bit, 
but NO 8-bit arithmetic is needed.
So, I thought, if a new custom-datatype can be added to the existing port, and only load/store functions can be attached to the variables of 
that datatype, it would be much simpler.

Please advice,
Thanks and Regards,
Sriharsha.

-- 
  *****************************
  * Sriharsha Vedurmudi			
  * Software Engineer		
  *
  * Redpine Signals Inc.	
  * Gate #395, Plot 87,88			
  * Sagar Society, Road #2,
  * Banjara Hills,		
  * Hyderabad - 500 034			
  * www.redpinesignals.com	
  *							
  * +91-40-23559911  (Office)
  * +91-98851-37338  (Mobile)
  *****************************

Re: New datatype addition to gcc

[Sriharsha]

Hi Eljay,       

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 
0x1001.

> 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??

> --Eljay


Thanks a Lot,

Sriharsha.

Re: New datatype addition to gcc

[Sriharsha]

Hi Michael,

Michael Meissner wrote:

>Note, GCC internally believes that all pointers are equal and are an integer
>type. 
>
That is known.

> If your port has two different types of address (ie, a pointer to 8 bit
>items would be different from a pointer to 16 bit items, either using a
>different format or a different sized item), it will be a long and difficult
>port.
>
My h/w personnel says that there will be TWO RAMs in the processor, one 
is 8-bit addressible while the other is 16-bit addressible. If the 
compiler has to do 8-bit data load/store, it uses the 8-bit RAM and if 
it has something to do with 16-bit, it uses that RAM. This sounded 
bizzare to me but, thats what they say (or atleast I've never come 
across such stuff).

>  I did the front end of the C compiler for Data General MV/Eclipse
>computers, which was originally a word machine that had byte modes grafted on
>(byte pointer was the word pointer shift left one bit).  At one point as we
>were doing the transition from MV/Eclipse to Motorola 8800, I looked at GCC,
>and concluded that it would be very difficult to support two types of pointer
>in the compiler.
>  
>
Completely agreed (though I have no clue how you do that)

>If your question is instead that you have a unifed pointer mode (word pointers
>having bottom bits zero), and you have load byte/store byte on the new machine,
>but no byte arithmetic, don't worry, most RISC machines have that restriction.
>GCC will just promote items to a larger integer type that does have arithmetic
>support.
>  
>
There we are. I was thinking exactly that. But again the problem of two 
RAM spaces is cropping up. Im totally stumped out here. I simply did not 
understand how the addresses are generated etc. (for eg. the arithmetic 
result of two 16-bit data can be 8-bit, then will it be stored in 8-bit 
RAM (thats what our ppl say))? And many such questions.

Im not sure if this is as unique a problem as I see or I'm still a 
novice in the processor world. Meanwhile our HW guys are busy with their 
works and have very less time for meetings on this issue.


Thanks again,
Sriharsha.