Re: [OT] Re: A86: C compiler

[Prev][Next][Index][Thread]

Re: [OT] Re: A86: C compiler


C++ and C are two entirely different languages.  I would dare say that Java
and C++ are closer to each other than C and C++.  Before someone starts a
big argument over that, I'll clarify what I mean.  I'm talking about the
language itself, and not the environment that Java is usually run in.
Ignoring the library calls, Java and C++ are quite similar, with the major
difference (as I've seen) is that Java cannot handle run-time-inheritance
but C++ can.

Being an object oriented language, C++ will generally create very poor code.
You can write object oriented code in straight C, though it will look quite
strange if people don't know exactly what you were trying to do.  Then
again, so can C++.  I've heard some of the early C++ compilers actually
converted the code to normal C, rather than compiling it directly.

While it is possible to write fast C++ code, you can write the same code in
C and it will probably be much more efficient.  The reason for this is that
you can accomplish the exact same things in C as C++, but people don't know
how or get lazy.  Anything like overloaded classes, inhertence, etc., will
simply kill performance.  Someone's got to do the thinking, and the compiler
will never do as good of a job as you.

Now, Small C is NOT C.  As far as I know, a Small C compiler was introduced
in Doctor Dobb's Journal.  Late eighties, anyone?  It was quite a while ago.
It has many limitations over regular C, the most outstanding probably being
the elimination of types.  However, the compiler WILL compile itself.  It's
been said that a good language should be able to write itself, but that's
another story.

Compilers are normally not designed to work with a specific platform or cpu.
If taking an academic approach to compiler design, a compiler will have a
front-end and a back-end.  Before the code can be run through the compiler,
a preprocessor will create an intermediate file out of all of the files to
be compiled.  Any preprocessor directives will be removed by the
preprocessor, before the compiler ever sees them.

The front end parses the source code and creates an internal representation
in intermediate code.  An optimizing compiler will do system-independent
optimizations on this intermediate code.  The back end, which is specific to
a cpu, will create the object code based on the intermediate code.  It never
sees the original source code, nor does it care.  The back end can perform
more optimizations to the code before it is produced.  After the object code
is generated, the code is run through a peep-hole optimizer.  The object
code is optimized entirely on the instruction level, mainly by reducing sets
of instructions with more efficient sets.  Because this can be a very
intensive process, it only looks at a small window of the code at once,
known as the peep hole.

There are many compilers specifically designed for the Z80, but these will
not create code anywhere near the efficiency than that of a human.  Even a
good optimizing compiler for the z80 could be beat by almost any assembly
programmer.

That said, I would guess that a Pascal compiler with a very good peep-hole
optimizer could create better code than a Small C compiler.  If only
standard pascal was supported, the language intensive features were ignored
(all the fun stuff that makes pascal so great like sets, character array
indices, etc.) and it supported direct inline assembly, coding could be done
pretty efficiently.

To use the 86's specific features would require coding library functions in
asm or doing them through inline asm.  I can't imagine how slow sprite
functions are in pascal.  I couldn't draw a screen with sprites in pascal on
my 486 without resorting to inline asm.  When I switched to C, the same code
was quite faster.  Though you can't beat compiling a program in under a
second in TP...

> I think we talked about these way back when someone suggested a C++
compiler
> for the 86.  What are they and how are they different from Small C?
> Anybody?  Oh, yes, and a matter of curiosity - aren't those compilers
> designed to work generically with the z80?  How is it, then, that we can
use
> them to do things with the 86's video, etc?
Follow-Ups: References: