Porting GCC without a working assembler and need for libgcc and other libraries

Porting GCC without a working assembler and need for libgcc and other libraries

[Etienne Fortin]

I developped an ISA (Instruction Set Architecture) from the ground up. I
have a working VM for that architecture. I also have an assembler and
various other utilities. I would like to add a C/C++/Fortran/Other compiler
for that architecture, and nothing is better than GCC in that respect.

Here's some problems:
1) The executable files have a format that is part ascii, part binary and is
not compatible with binutils.
2) The source are presented to the assembler in a format that is not
compatible with as (gnu assembler).
3) The assembler I developped can't be used with GCC for various reasons.

So in other words, there's no assembler for the architecture I can use with
GCC.

Here's what I want to do:
1) Create a cross compiler for the architecture that ONLY produce ASSEMBLER
source. No runtime, no crt, no other problems.
2) Postprocess the assembler source with Perl so that the format is OK for
the assembler I developped.
3) Assemble the file with my assembler.
4) ENJOY!

So the big question is........

Can someone tell me how I can build GCC so that NO runtime libraries are
build (not even libgcc) and in a way that the assembler is NOT needed (since
there's no assembler for the architecture). And next how can I create that
same GCC with the option -S always ON?

Anyone good enough here to answer that difficult question?

Etienne Fortin

Re: Porting GCC without a working assembler and need for libgcc and other libraries

[Michael Matz]

Hi,

On Tue, 30 Jul 2002, Etienne Fortin wrote:

> Can someone tell me how I can build GCC so that NO runtime libraries are
> build (not even libgcc) and in a way that the assembler is NOT needed (since
> there's no assembler for the architecture). And next how can I create that
> same GCC with the option -S always ON?

You could also create a dummy "assembler" which simply outputs it's input
again.  So you .s and .o files would be the same, and only the "linker"
would fiddle with these funny .o files (i.e. running them through your own
assember, and doing on them whatever is necessary to produce an
executable).  This way there are less changes to gcc itself.  And it
behaves more like other architectures, which makes it again more
appealing.


Ciao,
Michael.