On 29-Oct-2001 Russel Winder wrote:
> Can GCC linker scripts replace the explicit syntactic extensions used
> SDCC or are syntactic extensions the only way of handling compile time
> loading of interrupt vector tables and the address space partitioning
> the Harvard architecture?
If I am understanding the question properly, then my answer is that
syntactic extensions are not the only possible solution, but are
significantly better than the linker solution. The problem being not
interrupt vectors (this could quite easily be done via linker directives
and manually setting up the IVT, though SDCC's approach does add some
convenience) but the location of various other data items. For instance,
the question of 'is this array located in code space, data space or xdata
space' is of great interest to the code generator for the '390, since
different code must be generated to access code space and (x)data space,
and pointers to code/xdata are 3 bytes instead of 1 byte for data
pointers. Now, it is certainly possible to have the compiler generate
only code to handle generic pointers and let the linker do the fixups (so
that the compiler has no knowledge of what address space an array is in),
but this is so desperately inefficient as to be effectively useless.
So I would say that the data/xdata/code/generic syntactic extensions are
indespensible for a '390 compiler, at least, and probably for many of the
other processors in your class. Note that gcc already has the
'__attribute__' mechanism for syntactic hacks of this sort. The 'using'
keyword is another example where the knowledge simply must be available
to the compiler rather than the linker.
Of course, this does bring up a fascinating set of questions that our
friends at ANSI never had to deal with, like is a cast from an xdata
pointer to a data pointer legal? Should it throw a warning?
> Is there any previous work on using GCC for 8051 and/or other Harvard
> architectures (we will also be working with Cyan's eCOG1)?
I know there is an AVR port of gcc; apparently, there is also an lcc
port for the AVR. Both of these astonish me, because I looked at the
possibility of porting either or both of those to the '390, and lcc is
very, very 32-bit oriented, while gcc didn't seem much more amenable to
> How easy is access to the expression code generation (so that we can
> bind new code for pointer arithmetic as well as integer and floating
> point arithmetic)? Alternatively, is everything done through the
> library -- thereby making rebinding easy?
You will have to muck about with the code generator (possibly by making
pointer arithmetic call library functions (yuck!)). However, the code
generator is very amenable to such mucking about.
> How easy will it be to add 'long long' (we need to handle 64-bit
Aieee!! The mark of the beast!!
(sorry. I have a bad reaction to 'long long').
I'm not very wise in the ways of the SDCC front end, so I'm not sure how
complex that part would be. Unless you're in a significantly more
register rich environment that the 8051 family, 8 byte integers are going
to be a significant code-generation challenge. I would be very tempted to
implement them via an external library a la floats. This will not be
trivial, imho, but is certainly do-able.