Can anyone point me at a good existing implementation of
GO_IF_LEGITIMATE_ADDRESS, suitable for a microcontroller with banked
(segmented) 8 bit registers?
How about a pull-together of all the existing docs on how to create a new
front-end / back-end.. stuff like whats in the gcc internals doc, and
Stallman's "Using and porting gcc".. maybe update it all in a single place
for ver 4.x, and update for the undocumented / obsolete macros? It's not
st
I'm not quite sure I follow you.. if its possible to dedicate a register to
act as the data-stack pointer, and implement it that way, why would I want
to "keep the SP as a virtual register"? I'm not being antagonistic when I
say that.. I'm just trying to understand what you're trying to tell me
I'm not dependent on it, although at some point, I'm sure i may take a
closer look at the code to see how they've done certain things.
Just as a reminder, even though the Microchip code is covered by the GPL,
code based on it >>won't be acceptable for inclusion into FSF GCC unless
you can get
Happy days.. That wasn't obvious to me. I'll check out the details later.
Thanks.
Colm
The PowerPC (look in config/rs6000) has no stack.
All GCC needs is that you define a register to be the stack pointer
(STACK_POINTER_REGNUM) and this register doesn't have to be a base register
(see "Addre
Does anyone have any ideas about what gcc support is like for targets with
no data stack? The 14 bit cores (16F) mostly have a 2-8 level hardware
stack, which is not part of the program or data memory, and is not
addressable. There is no data stack.
I'm hoping that there is an existing backe
I will probably start working on a 18F back-end if no definite plans for
implementing a complete port materialize 'soon.' (that is, if no-one else
seems likely to produce anything within the next few months)
Well I suppose these things need to start from individuals grouping
together.. I'm hap
See also the recent mails on "Re: GCC port for V8-uRISC (8 bit CPU)", which
I'm not really familiar with yet, but which could be very relevant.
Colm
Aaron,
I'm currently working on this, for one. I'm in the very early stages of
development.
I'm currently using the following GCC ports (backends) for references
purposes: AVR, m68hc11/12. My code is currently based on GCC 3.3, but I'll
migrate to mainline as soon as I have any changes out
Theres an interesting discussion going on as to whether Microchip Inc is
allowed by the GPL to licence linker scripts and some other scripts (their
code, not based on a GPL'ed code) when these scripts are all distributed as
part of the MPLAB C30, which is a C compiler, based on the GNU CC (gcc)
It seems that there is already a PIC port for gcc.. in the form of
Microchips own MPLAB C30 compiler.. I didn't realise this (and google
certainly didn't tell me) until I had started on the PIC14 port for gcc, and
went to the Microchip website for some info, and searched on "C compiler"
and the
always produces assembler output (which may or may not be saved to a
file).
Colm O' Flaherty wrote:
All,
I've been thinking a bit more about this (no code yet: I was busy trying
to find and fix a bug in gpsim), and I'm still not sure what the optimal
development mode is..
try learn from mistakes there, and gain
some experience?
From: Mike Stump <[EMAIL PROTECTED]>
To: "Colm O' Flaherty" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
13 matches
Mail list logo
