Comment by Someone | Hacker News Reader

Comment by Someone | Hacker News Reader

"However, Alto microcode is pretty crazy, so I'm not going to try a microcode Mandelbrot."

I don't understand that logic, coming from somebody who has a restored Xerox Alto and wrote a Mandelbrot generator in BCPL for it "to learn how to use the Alto's bitmapped display, not make the fastest Mandelbrot set".

I also expect this guy will get source code for the 'simple' things such as an OR instruction or a fixed-width multiplication instruction within a few weeks.

Edit: I’ve been browsing http://bitsavers.trailing-edge.com/pdf/xerox/alto/Alto_Hardw....

There apparently are only 16 basic micro-instructions (”The ALU function field controls the SN74181 ALU. This device can do a total of 48 arithmetic and logical operations, most of which are relatively useless. The 4-bit field is mapped by a PROM into the 16 most useful functions”), and OR is one of them:

       ALUF  FIELD FUNCTION  
         0   BUS            (A)
         1   T              (B)
         2   BUS OR T*      (A+B)
         3   BUS AND T      (AB)
         4   BUS XOR T      (A XOR B)
         5   BUS + I*       (A PLUS I)
         6   BUS - I*       (A MINUS I)
         7   BUS + T        (A PLUS B)
        1OB  BUS - T        (A MINUS B)
        11B  BUS - T - 1    (A MINUS B MINUS I)
        12B  BUS + T + 1*   (A PLUS B PLUS I) 
        13B  BUS + SKIP*    (A PLUS I) 
        14B  BUS.T* (AND)   (AB) 
        15B  BUS AND NOT T  (A & NOT B)
    16B-17B  UNDEFINED

So, following the best source I have, (that PDF) which states:

”For the most part, since the Alto is such a simple machine, writing Alto microcode is a straightforward exercise in rule-following”

that shouldn’t be too hard, provided that there is a free spot for writing the microcode instruction, or that you can find an instruction to give up in exchange for a simple OR.

Edit 2: that PDF also describes the way you do an OR, so that apparently was the way to go:

”To "or" together the contents of ACO and ACI; results ACO:

    COM 1.1
    AND 1,0
    ADC 1,0

”

The microcode isn't quite as simple as you make it sound. Trust me, I've needed to understand a lot of the Alto's microcode to debug disk and other issues, and it's brain-twisting.

There are the 16 basic ALU micro-instructions, but these are combined with 8 different bus sources and two sets of "special functions" to make fairly complex micro-instructions. The special functions are a bit crazy and also totally change meaning depending on which hardware task is running.

Control flow in microcode is pretty wacky. Each micro-instruction contains the address of the next micro-instruction, so it's like a goto in every instruction with instructions randomly scattered through memory. Additionally, branches are done by the hardware setting bits in the address based on conditions, so you end up with basically a computed goto. Finally, branches happen the instruction after the condition. So even just following the control flow of microcode is hard.

Another fun thing with microcode is that to read memory you write the address to the memory address register. Then you need to wait two microinstructions before you can read or write the memory value.

If you want to take a look at the Alto's microcode: http://bitsavers.trailing-edge.com/pdf/xerox/alto/microcode/...

Yes, I saw a bit of that, and did realize what you meant by pretty crazy. Rereading my last edit, I also notice that the smiley I had there got lost in editing. Apologies for that.

If you do have the microcode for AND, and a RAM board to store custom microcode, creating an OR instruction shouldn't be insanely hard, though, even without an assembler (finding a spot to put it without losing another instruction may be impossible, though, and that could mean a fairly large rewrite of your OS and applications)

Also, branch delay slots (https://en.wikipedia.org/wiki/Delay_slot#Branch_delay_slots) apparently predate RISC.

Well, the microcode for AND is simple; it's this line

G17: L_ ACDEST AND T, TASK, :SHIFT;

...the problem is that that's in the middle of the decode (there's a computed jump into this lot from the line labelled DIS1:). So you could change the AND insn to do OR instead, trivially (use "OR" here where the line says "AND"), but you probably wanted to keep AND. So you'd need to at least add enough of your own decode to be able to put the insn somewhere else. And as you say that looks like the real problem: http://users.rcn.com/crfriend/museum/doco/DG/Nova/base-instr... suggests that given 16 bit instructions and the format they've used there isn't much space left. The best you could do would be to steal some of the 'io instruction' space and have it operate on fixed accumulator registers the way MUL and DIV do.

(The decode is remarkably confusing even knowing what it's supposed to be doing; there seems to be a lot of implicitly jumping to entries in decode tables based on bits of the instruction...)

Looks like you've figured a lot of it out, but if you want more details... The way instruction decoding works is the hardware slams some of the instruction bits onto the microaddress bus, causing a 16-way dispatch based on the instruction, selecting which instruction to execute. In detail, looking at the microcode:

  !17,20,GETAD,G1,G2,G3,G4,G5,G6,G7,G10,G11,G12,G13,G14,G15,G16,G17;
  DIS0:	L←T←IR←MD;
  DIS1:	T←ACSOURCE, :GETAD;
  GETAD: T←0, :DOINS;			PAGE 0
  G1:	T←PC -1, :DOINS;		RELATIVE
  G2:	T←AC2, :DOINS;			AC2 RELATIVE
  ...
  G17:	L←ACDEST AND T, TASK, :SHIFT;

"IR" is the special instruction register. Loading it from memory (MD=Memory Data) causes a dispatch after the next microinstruction. ":GETAD" is a microcode branch, so the next microinstruction after DIS1 would normally be at label GETAD. However, IR causes bits 0,5,6,7 of the instruction to get OR'd into the microaddress, resulting in the dispatch to G1, G2 etc. But how does the microassembler know that G1, G2, etc need to be aligned properly for this to work? That's what the !17,20 directive does: 17 and 20 are the necessary alignment in octal, followed by the list of labels that need to be aligned.

Further instruction decoding is done with the IDISP and ACSOURCE special microcode functions, which do more complex decoding (based on multiple bit combinations) resulting in similar dispatches. So the branch to :DOINS or :SHIFT will do a second dispatch, based on the earlier ACSOURCE.(See page 30 of the hardware manual for details.)

Actually, the PARC guys stole all of the io instruction space for other things on the Alto. Only the math and load/store instructions are compatible with the Nova.

Even if I were crazy enough to write microcode, there's a problem that we don't have the microcode assembler MU.RUN. Maybe it will turn up on one of the PARC disks we're archiving...

Interesting, I hope that the archives end up available to the public. It'd be really neat to build some kind of functional emulator like the visual 6502 to play around in. Do it on a block level for the CPU so you can examine the state as things happen.

Funny you should mention that, because the Living Computer Museum wrote a high-quality emulator (ContrAlto) for the Alto. It's super-accurate, even emulating the microcode and hardware, and runs at the speed of the live machine. It includes a debugging mode that lets you examine machine state and step through machine instructions and microcode. Source: https://github.com/livingcomputermuseum/ContrAlto

ContrAlto was very helpful while getting the real Alto running, and I also use it for developing software such as the Mandelbrot. I wrote a guide to getting started with ContrAlto: http://www.righto.com/2016/10/simulating-xerox-alto-with-con...

Awesome I'll check that out. I think I remember looking back when this started and found SALTO but it appears to be incomplete and buggy. ContrAlto looks interesting.

Theres a mu.run on (at least) one of the disks archived at the Computer History Musuem, listed at

http://xeroxalto.computerhistory.org/_cd8_/alto/.index.html

http://xeroxalto.computerhistory.org/_cd8_/alto/.mu.run!2.ht...

but I don't know if there's any way to transfer it from a disk image to an actual Alto disk?

Thanks - I searched that archive for MU.RUN but somehow missed it. We got a gateway from the Living Computer Museum that lets us transfer files to the real Alto. So I guess I need another excuse for why I'm not writing microcode :-)

Pardon my ignorance, but does the Alto multi-task between user programs? If the answer to that question is affirmative, how does the machine cope with simultaneously running two programs that load different custom microcode? Does it load and unload and reload at every context switch? Or does it simply not multi-task?

The Alto is a "personal computer" and only runs one program at a time. The operating system provides primitive task management (sort of like threads) so the operating system can for instance process network packets while a program is running, or a program can contain multiple tasks. Thus, a program can load the microcode it needs when it starts up and doesn't need to worry about conflicts.

This task management is entirely orthogonal to the 16 tasks that are running at the microcode level to refresh the display and handle I/O devices.

Reply on news.ycombinator.com