Re: A86: What C-compilers have we got? [82/83/83+/85/86]
[Prev][Next][Index][Thread]
Re: A86: What C-compilers have we got? [82/83/83+/85/86]
On Thu, 16 Nov 2000, Michael Perley wrote:
>
> As I've read through all of this, I've noticed you've all left out a
> possibility, and I'm wondering why.
>
> Why can't you just make a C-compiler that compiles into machine code? If it
> compiles to asm, then it is only obvious that it will have to be compiled
> AGAIN to machine code, so why don't you just skip the middleman and go
> straight to machine code.
>
> Or, does this require too much time and/or programming experience?
One reason it's a little easier to write assembly code first is that the
compiler can then ignore some things, like assigning label
addresses. Also, if the compiler writer doesn't know all the opcodes,
then writing assembly has the advantage you don't need to repeatedly refer
to the opcode table when writing the compiler.
Also, debugging the compiler is easier since you can just look at its text
output (which you can easily make the compiler add comments to to help you
figure stuff out).
Last, remember that if you wanted to mix assembly and C code, then the
compiler would then have to be an assembler and a compiler to do it all in
one step. This is probably the case with most calculator compilers, since
the startup code and some other routines are written in assembly. So the
compiler would have to turn C to machine code, and assembly to machine
code, versus the current case where it's only needed to turn C into
assembly.
Other than those things, I don't think it's that much harder. If the
compiler is written in C itself, it shouldn't be harder to write binary
machine code output than to output text strings.
But I don't think it's a terrible disaster to have to run an
assembler.
References: