BL> It was interesting going back to C after so long, and I can see
BL> why people like writing the code. Pascal is verbose by
BL> comparison (which is why it's easier to read), but I still
BL> prefer the Pascal approach. 

PE> Look at the generated object code to see whether the code
PE> actually generates worse assembler.

BL> I've been doing that, adding up clock ticks as well as running
BL> profiler tests, and Pascal impresses the shit out of me. It varies a
BL> bit, but 20% off optimum ASM is about the result for small functions.
BL> That's *very* good.

Show me the comparison to the C code, and I'll show you what you did wrong
in the C programming.

BL> Do you know where I can get the 286/386 instruction set? Just the

I thought you got a little manual, and a big manual, with Turbo Assembler,
which you got from David Begley?

BL> summary, listed by group: Data Transfer, Arithmetic, etc. I've still
BL> got keith's book which is perfect, but I can't find a similar list on
BL> the BBS. ASM editor help files go into detail, but they all seem to
BL> assume you already know the set (which I don't) and if I don't know
BL> the names how can I look them up? Bloody dickheads!

Oh, you mean on the BBS.  If INT*.* from 3:711/934 doesn't have it (Ralph
Brown's interrupt list) then I don't know.

PE> For .exe size comparison, you either need to strip out some of
PE> the baggage that comes with C (or make sure you don't drag it
PE> in!), or do a real test, which is use a big program, where the
PE> runtime support is bugger-all. BFN. Paul. 

BL> I already know big C programs have smaller EXEs than Pascal, but I
BL> was talking about small utilities in the <16K area (to annoy you).

Only the .exe size could win, not the quality of assembler generated.
Certainly not when processed through Watcom C.  BFN.  Paul. 
@EOT:

---