Re: New datatype addition to gcc

Sriharsha Vedurmudi wrote:
> 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.


The only problem that I have heard of that is remotly similar is the
issue of the 2 address spaces that a OS kernel has to deal with, but
even then the sizeof the load/stored data is not the issue, only which
side of the fence it sits on. sparce was written by Linus Torvalds to
deal with this and several other issues with Linux, but it is mainly
used for checking code for proper use of pointers and popper use of
aquired resources -- stuff like making sure that resources are released
in all execution paths from where they are aquired and not in pathes
that they shouldn't be released from.


What is this processor's notion of a stack? Does it have one in each
RAM? What about .text area? Is that in the 16 bit RAM or in its own
separate RAM or is it streamed in through some other something?


You might be able to shoe-horn+duct tape something together if you
allocate everything out of the 16 bit RAM except for char and char[]
when they are not in a struct or union, but stack dynamic variables
could still be a royal pain unless it has a stack in each RAM. You
would also not be able to do it for any char * (or &char) that might
be typecast. Maybe const char[] and const char could go there w/o
too much pain, but the casts would still have to be looked out for.


Anyway you look at it, using GCC for this would be a pain and require
WAY HARD!
You might just want to include some special header and library or inline
functions that can access this RAM.


typedef struct{char * prt} ptr_8;
inline char get_8(ptr_8 a){ /*stuff here */}
inline void put_8(ptr_8 a, char b){/*other stuff here */}
...


Except that I don't know about how the pointers are done and it may be
that there is no way to tell the difference in an address to a high or
low byte -- like the byte after binary(0000) would be binary(0000.1)
rather than binary(0001), but you could have hi/low versions or
something. Or you could use the high order bit to distinguish and tell
the HW guys not to ever put enough RAM on that bank to matter. This
would effectivly add yet another address space though -- the normal 16
bit one, the lower 8 bit one, and the upper 8 bit one. This would
difficult to use, but it would allow the RAM to not be wasted.


Nathan

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