Re: New datatype addition to gcc

Sriharsha Vedurmudi <sriharsha.v@redpinesignals.com> writes:


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


Note, GCC internally believes that all pointers are equal and are an
integer type. 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. 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.


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.


--
Michael Meissner
email: mrmnews@the-meissners.org
http://www.the-meissners.org

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