Re: New datatype addition to gcc

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.

Return to the comp.compilers page.
Search the comp.compilers archives again.