Re: Compile HLL to microcode on VLIW - possible?

preston@tera.com (Preston Briggs) wrote:


> This is just some of the old-time religion behind RISC. In the old
> days, the CISC machines had a microcode interpreter that ran
> microinstructions stored in the microstore. A single
> microinstruction, fetched from the fast microstore, could be
> executed much more quickly than a machine instruction could be
> simulated (the microinstructions were also wide, so the many little
> functional units could be controlled at once).


> Seeing the difference between microcode execution speed and the
> speed at which the machine's "native" instruction set was emulated,
> people started making use of programmable microcode. Made their own
> special-purpose machines with custom instruction sets (e.g., the
> Dorado) or compiled to it directly (e.g., Patterson's early work and
> apparently the Culler).


and based on what I used to hear my father talk about, the Burroughs 6700..


> When the 801 came along, they said: no more microcode! Instead,
> have an instruction cache and make the basic machine cycle as fast
> as the old microcode engines. If you want to do something complex
> (like division), call a small subroutine that'll probably live in
> the cache (if it's used often enough, or expand the routine inline)
> and it'll take about the same number of cycles as the old microcode
> version of division did.


> As a bonus, you expose the guts of these complex instructions to the
> optimizer, making new opportunities for CSE elimination, constant
> folding, etc.


> And that's the whole deal. With instruction caches, you can make
> the hardwired instruction cycle as fast as microcode. There's no
> reason to have a separate level of instruction interpretation.


Hmmm.. I have to wonder how all of this relates to the MMX extensions
that are being included in the Intel Pentium processor, based on the
cursory review that I've done to this point, they have recoded the
instruction set for the FP unit so that it can be used to do graphics
operations, and as a result, they expect full screen real time video
as a base line operation of the chip..


Perhaps a more accurate statement is that there is ALMOST no reason to
have a separate level of instruction interpretation, (unless you want
to be able to manipulate chip design based on market realities..)


Wilbur
[RISC chips often seem to have floating point, apparently because even though
FP is complicated, breaking it down into smaller pieces makes it slower and
the individual pieces don't seem to be very useful for other stuff. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.