Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microcode: the place where hardware and software meet

alanwinfield.blogspot.co.uk

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Microcode: the place where hardware and software meet

#11

Post by jonsen »

nixbun wrote: post #5

A bit off topic, but I've always wondered why some refer to the language as 'assembler' whereas others call it 'assembly'. I always thought the assembler is the name of the thing that reads in your assembly code and turns it into a machine binary. Is there some historical significance to calling it 'assembler'?

Calling the language assembler might be considered potentially confusing and ambiguous, since this is also the name of the utility program that translates assembly language statements into machine code. However, this usage has been common among professionals and in the literature for decades.:

http://en.wikipedia.org/wiki/Assembler_(computing)#Assembler

Re: Microcode: the place where hardware and software meet

#13

Post by cnvogel »

gngeal wrote: post #3
codeulike wrote: post #2

The original ARM RISC design did away with Microcode, with the chip executing instructions directly, although I think it might have crept back in since then http://en.wikipedia.org/wiki/ARM_architecture#Instruction_se...

There are many more machines without microcode - 6502, machineForth chips like f21, c18 etc. I'd argue that they are much more appealing to a designer with taste.

I think that the 6502 decode ROM which matches opcode bits and sequence numbers to internal CPU functions is a very good example. It can be seen as either just a rather complex demultiplexer or, with keeping the sequencing nature in mind as a minimal, hard coded, computer program.

Does microcode have to execute like traditional software to be called microcode?

Re: Microcode: the place where hardware and software meet

#14

Post by StephenFalken »

codeulike wrote: post #2

The original ARM RISC design did away with Microcode, with the chip executing instructions directly, although I think it might have crept back in since then http://en.wikipedia.org/wiki/ARM_architecture#Instruction_se...

"RISC architecture eliminates microcode routines and turns low-level control of the machine over to software. The RISC approach is not new, but its application has become more prevalent in recent years, due to the increasing use of high-level languages, the development of compilers that are able to optimize at the microcode level, and dramatic advances in semiconductor memory and packaging. It is now feasible to replace relatively slow microcode ROM with faster RAM that is organized as an instruction cache. Machine control resides in this instruction cache that is, in effect, customized on-the-fly: the instruction stream generated by system- and compiler-generated code provides a precise fit between the requirements of high-level software and the low-level capabilities of the hardware."[1]

-- MIPS R4000 Microprocessor User’s Manual, Chapter 1, Page 2

[1] http://groups.csail.mit.edu/cag/raw/documents/R4400_Uman_boo...

Re: Microcode: the place where hardware and software meet

#15

Post by ColinWright »

dag11 wrote: post #7

Donn Stewart has a very enlightening and relatively simple explanation on the very basics of how a CPU works, which includes a great explanation of microcode and the control cycle. http://cpuville.com/cpu_design.pdf And here's his main site: http://cpuville.com

Clicking on http://cpuville.com/cpu_design.pdf gives me:

    Forbidden
    Remote Host: []

    You do not have permission to access this
    page or file

    Data files must be stored on the same site
    they are linked from.
To see the PDF you need to visit the main page and then click through. Fortunately, if you first try the forbidden page, the link you want will already be purple for you.

Re: Microcode: the place where hardware and software meet

#16

Post by williadc »

StephenFalken wrote: post #14
codeulike wrote: post #2

The original ARM RISC design did away with Microcode, with the chip executing instructions directly, although I think it might have crept back in since then http://en.wikipedia.org/wiki/ARM_architecture#Instruction_se...

" RISC architecture eliminates microcode routines and turns low-level control of the machine over to software. The RISC approach is not new, but its application has become more prevalent in recent years, due to the increasing use of high-level languages, the development of compilers that are able to optimize at the microcode level, and dramatic advances in semiconductor memory and packaging. It is now feasible to rep…

Having read just to that point in the book, it seems this information is a bit old. Modern x86 processors have microcode ROMs on die, so the performance penalty is near zero.

Re: Microcode: the place where hardware and software meet

#17

Post by krapp »

ColinWright wrote: post #15
dag11 wrote: post #7

Donn Stewart has a very enlightening and relatively simple explanation on the very basics of how a CPU works, which includes a great explanation of microcode and the control cycle. http://cpuville.com/cpu_design.pdf And here's his main site: http://cpuville.com

Clicking on http://cpuville.com/cpu_design.pdf gives me: Forbidden Remote Host: [ ] You do not have permission to access this page or file Data files must be stored on the same site they are linked from. To see the PDF you need to visit the main page and then click through. Fortunately, if you first try the forbidden page, the link you want will already be purple for you.

I can see it by turning off my referer in Firefox.

Re: Microcode: the place where hardware and software meet

#18

Post by kens »

cnvogel wrote: post #13
gngeal wrote: post #3

Earlier quoted context omitted.

There are many more machines without microcode - 6502, machineForth chips like f21, c18 etc. I'd argue that they are much more appealing to a designer with taste.

I think that the 6502 decode ROM which matches opcode bits and sequence numbers to internal CPU functions is a very good example. It can be seen as either just a rather complex demultiplexer or, with keeping the sequencing nature in mind as a minimal, hard coded, computer program. Does microcode have to execute like traditional software to be called microcode?

The 6502 is an interesting case. The decode ROM (PLA) gets instructions about 1/3 of the way decoded, and then there's a whole pile of random control logic [1], [2] that generates the actual control lines [3]. The output from the decode ROM consists of semi-meaningless things such as ADC/SBC in state T0, or JSR in T5 [4], and after a whole bunch of gates these get turned into the actual control functions such as S bus to A register. [3]

[1] image of the 6502 at http://www.visual6502.org/images/6502/index.html

[2] schematic http://www.visual6502.org/wiki/index.php?title=650X_Schemati...

[3] block diagram http://www.weihenstephan.org/~michaste/pagetable/6502/6502.j...

[4] details of ROM http://visual6502.org/wiki/index.php?title=6507_Decode_ROM

Re: Microcode: the place where hardware and software meet

#19

Post by cynwoody »

Breakthrough wrote: post #4

Reminds me of this question on Super User: How does a CPU 'know' what commands and instructions actually mean? http://superuser.com/questions/307116/how-does-a-cpu-know-wh... Microcode in its most basic form is just a big look-up table (could be nested if word size is limited) containing the electrical signals for a particular instruction, and a new address to "jump" to (either a subsequent micro-operation, or jump b…

> You can change the operation of instructions after the hardware is made, make custom sequences of instructions, or even fix microcode bugs (while uncommon, there have been cases in the past).

I am reminded of the famous Intel Pentium FDIV bug (1994). Seems they had implemented a new and improved floating point division algorithm. It needed only half the cycles of the previous algorithm.

The new algorithm used a 1066-cell lookup table to find partial quotients used in the calculation. Unfortunately, due to a screwup, five of the cells were left blank when the ROM was loaded. This led to obscure errors in the results, which went unnoticed until many thousands of chips were in customers' hands. At that point, Intel had a massively embarrassing recall on their hands.

http://engineeringfailures.org/?p=466

http://www.trnicely.net/pentbug/pentbug.html

Re: Microcode: the place where hardware and software meet

#20

Post by grannyg00se »

kens wrote: post #18
cnvogel wrote: post #13

Earlier quoted context omitted.

I think that the 6502 decode ROM which matches opcode bits and sequence numbers to internal CPU functions is a very good example. It can be seen as either just a rather complex demultiplexer or, with keeping the sequencing nature in mind as a minimal, hard coded, computer program. Does microcode have to execute like traditional software to be called microcode?

The 6502 is an interesting case. The decode ROM (PLA) gets instructions about 1/3 of the way decoded, and then there's a whole pile of random control logic [1], [2] that generates the actual control lines [3]. The output from the decode ROM consists of semi-meaningless things such as ADC/SBC in state T0, or JSR in T5 [4], and after a whole bunch of gates these get turned into the actual control functions such as S bu…

"Random control logic" Oxymoron?

Is the control logic really random in some way? That sounds impossible. Or at least, very highly inefficient.

Post reply on HN