6105407@pucc.Princeton.EDU (Matthew Kennel) (10/23/87)
I have a bit of a complaint about Lightspeed C for the mac.
The environment's excellent; I like the editor, the 'project' concept,
and the relativistic linker. The only problem is the compiler's poor
code generation.
Specifically, I am talking about things such as unnecessary tests, and
primarily, stupid register shuffling and addressing of data.
For example code such as d := a[i] if all variables are registered seems
to be compiled into :
LEA x(A6),A0
ADD.W A0, D0 !(or maybe it's the other way around)
mov.w (a0), d5
The 68000 provides just such an adressing mode to do this :
Mov.W X(a6, d0.w), d5
In addition, this saves a register (A0) that could now be used to hold
intermediate values. The 68000 isn't a RISC chip, so the compilers shouldn't
be making code as if it were.
In addition, there seems to be much silliness as :
MOV.w x(A6),d0
ADD.w blah, d0
Mov.w d0, d7
when you do an operation on a register variable (d7); why not do something like
mov.w x(a6),d7
add.w blah, d7
Furthermore, I've seen alot of things like this:
mov.w x(a6),d0
tst.w x(a6) !totally superfluous
beq bomb
Also, I have never been able to make it make code that does auto-increment
addressing, even when the C code does! (why else on earth would one write
blah = *s++ + garbage if not to make the reference to s (presumably a register
variable) auto incrementing?
If you want to be sick, take a look at the code for
while (*s++ = *t++) (* famous C idiom *)
It should be
label: move.b (t)+, (s)+_
bne label
Also, the DBcc instruction never seems to be used. The documentation says
use while (--i >= 0) for a fast loop, so I assumed it would compile a
dbf d7, label type of instruction, but no.
It seems I can always tell an assembly program from compiled code because
it uses either the mov x(a0, d0), * addressing mode, autoincrement or
decrement for something other than a push to the stack, or the DBcc family
of instructions.
I'm not asking for global data analysis, automatic pointerizing, or
removing invariant expressions from loops, just decent code generation
for the 68000. Of course, there's no reason the other things couldn't
be done: the mac's not a toy computer.
Do all the Motorola compiler gurus work for Sun or Apollo or what?
No wonder why the '386s come in with better benchmarks than the Mac II.
===========digression follows...========
I have another question: Is it true that 68881 instructions generate
traps on mac's without them? If so would it be possible for software
to simulate those instructions (via Sane or whatever)?
So then why wasn't the floating point set up so that all the compilers
would make real '881 instructions from day 0, at first simulated with
software (no slower than the current method of calling SANE), and
when it was run on a computer with the hardware, the 881 would kick in
automatically. That way, ALL mac software in existence would run
on the mac II at native 68881 speeds, and we would never have to
worry about compatibility. Isn't that what those illegal instruction
traps designed for???
Matt Kennel (6105407@pucc on BITNET; I have no idea how the unix nets work)
ps: I have LSC 2.01