Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: 80486 vs. 68040 code size [really: how many regs]
Message-ID: <948@aber-cs.UUCP>
Date: 15 May 89 16:49:05 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 111

In article <8082@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes:
    
    I program a 68000 a lot. I suspect a 68000 is a fairly typical
    reg-memory machine. I write a lot of "C" code. The "C" compiler I'm
    using is fairly PCC-like, i.e. loses all register values between
    expressions. In performance-critical portions of the code, I end up
    modifying the assembly language output to keep as many values in
    registers as possible.

This is because you are one of the many C programmers that do not understand
"register" variAbles. Too bad for you and your work.

    This is especially important with globals, because they can't be put
    into registers normally.

If you use them intensively in a small section of code, you can assign them
to local register variables. But, a good programmer knows that if a program
uses intensively global variables, then probably program structure is wrong.
There is one good documented case where global "register" variables are
useful, and it is for interpreters, where you want to keep some of the state
of the simulated machine in global registers, because by definition they are
used/modified continuously.

    Presto, fewer instruction bytes, as much as 20% improvement in
    performance. If only the compiler did it for me, eh?

Because you are not good enough to do it yourself. Admittedly, a compiler
probably generates code that is more reliable and better than that done
by programmers that understand their language and the realities of their
codes well.

    > used little. In a reg-mem architecture little use variables in memory do not
    > carry costs as high when you use them.
    
    Foo. If you use the variable three times, you've saved 4 memory
    fetches (2 addresses, 2 data) as vs. keeping it in a register. No matter
    what kind of machine you're using.

The cost is in adding instructions. John Mashey, that does understand architectures,
said that this is not so important because you can use delay slots etc...
This is true, but the resulting code expansion 

Moreover your statement demonstrates of shallow understanding of codes and
chips:

Point 1: competent programmers know that codes consume most of their time
in tiny spots of the code, tipically in loops. Optimizing the rest usually
does not matter much (except for size).

Point 2: competent architecture designers (save for those that work for Intel
and other companies that can afford 1.2 millions of transistors :-/) know
that adding registers beyond what is needed has a cost, both (small) in chip
complexity, and in speed (because if you use them you have to save/restore
them at some point in time), which is well known to those that use C
competently:  using "register" inappropriately can *slow* your program (on a
reg-mem machine).

Again, as to the last point, if you have enough registers, the register file
becomes a kind of first level memory, so you can keep your stack, and globals
there. But then you pay in system terms at context switching time.

    >>     Why don't you like inter-expression register assignments?
    > Well, I like them, as long as the compiler does not do them, but the
    > programmer does, by using explicit "register" declarations. But
    
    Have you ever looked at the output of a "C" compiler, and compared the
    output of GCC to PCC (i.e. optimizing compiler vs. non-optimizing)?
    Re-compiling a program with GCC is a sure-fired way of speeding it up
    by 20% ;-).

This does not happen to my programs, when it matters. Why does it happen to
yours? :-( :-). Also, that 20% improvement may come at the expense of
reliability; the higher the optimization, the hairier the code generator,
the greater the risks. RMS itself said that he is disappointed at the time
it is taking to beta test a large complex, even if well written, beast like
gcc. Gcc/g++ does improve my programs however in two ways:

	1) code size. Admittedly PCC does not generate the densest code,
	because it code generator tables and pattern matcher is not quite as
	sophisticated and thorough as PCC's. On the other hand, the latter
	takes one tenth/one fifth the memory, while being a bit slower --
	PCC's tables are interetred, Gcc's are compiled -- if each is given
	unlimited memory, while being very much faster in limited memory.

	2) readability. Inlining is so much better than writing cpp macros...

    [ ... ] but, anyhow, your reg-mem architecture is blown all to heaven by
    what the RISC folks have actually PRODUCED IN SILICON, i.e. it is NOT
    the bemused speculations of a goggle-eyed grad student).

I never quite realized that the 32532, Novix, CRISP, Transputer (to cite my
favourites from CISC, RISC and RISCy camps) were bemused speculations by
"goggle eyed" grad students. Thank you for letting me know. :-(.

    > Note that It is assumed that RISC == reg-reg, and that load-store == reg-reg;
    > neither these equations are necessarily true, as one could have RISC ==
    > stack-stack or load-store == stack-stack... 
    
    stack-stack must be reg-reg in order to be adequately fast.
		^^^^

    But note that program-memory bandwidth is the one thing there's no
    shortage of.

Enough of this unsupported nonsense... Try read something about the machines
above. Don't believe every urban legend you hear :->.

-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk