4 ms·

My first job out of college was to write a polygon fill routine for the TMS34010 graphics processor. I developed a love for it's clean 32-bit risc architecture

My first job out of college was to write a polygon fill routine for the TMS34010 graphics processor. I developed a love for it's clean 32-bit risc architecture ... it was even bit addressable with a flat address space. I actually loved programming in assembly language ... you could fit most subroutine arguments in registers.. use any of 32 registers you pleased. Later I did some 8086 assembly programming. I learned why a generation of programmers hate assembly... only a few special purpose registers, segmented memory, long list of nonorthogonal instructions, ... yuck I blame the general aversion for assembly programming to the choice of using the 8086 for PC's.

dreamcompiler 9y ago
The 34010 was indeed a sweet chip. I once wrote a Forth compiler for it in assembler as an exercise. Coding graphics in Forth was a joy. And yes, Intel's instruction sets are so butt-ugly they make everybody else's look beautiful by comparison. I really wish almost any other chip had won the war for that reason. I'm encouraged by the rising profile of ARM.
megablast 9y ago
> I blame the general aversion for assembly programming to the choice of using the 8086 for PC's. I loved 8086 assembly after coming from Z80. And one of the reasons it was so fast was because of minimal registers. And 8086 was released 10 years earlier.
joezydeco 9y ago
If you played any of the Williams Electronics or Midway arcade titles from the late 1980s through the mid-90s (NARC, Smash TV, Cruis'n USA/World, Mortal Kombat 1/2/3, Terminator 2, NBA Jam, etc) they were all done on the TMS34010 or 32031...all in assembly language.
- gp2000 9y ago
  Emulation of that processor was a bit of a challenge. Fortunately the fully general bit addressibility was only used in gzip decompression and the drawing instructions (circles, rectangles, that sort of thing) only came up in test mode. So not all of it had to be implemented and only the normal 8/16/32 bit addressing modes had to be fast.
pjmlp 9y ago
Not everyone hates x86. I had lots of fun coding for with, initially with as86 and then TASM. The only thing I hated with the x86 was trying to use AT&T syntax a few decades later. I also coded for Z80, 68000 and MIPS.
- waynecochran 9y ago
  I have learned three different syntaxes for the same x86 instruction set: [MBTN]ASM (DOS/WIN16/32), GNU assembly, and Amsterdam compiler kit (Minix). All of them used different mnemonics, a different notation for addressing, and couldn't decide between MOV SRC,DST and MOV DST,SRC. Then you had real mode vs protected mode which used the same segmented registers in a completely different way -- a clever way to be backwards compatible -- long story. In real mode you have a variety of different memory models: tiny, small, large, ... -- near and far ptrs? -- ugh. 20-bit physical addresses from segment << 4 | offset. Uggggllllyyyyy.... Forget about the x87 floating point processor -- arguments go on a 8-level deep stack -- really? I got to push and pop to do floating point? Now you have AMD-64. But all that old stuff is still there taking up transistors!
  - Pica_soO 9y ago
    Not really.. the API is still there, behaving like a backwards compatible processor, but deep down- there is no reserved silicon for this- just pipelines, getting microcode.
    - waynecochran 9y ago
      Naive architecture question: where is the microcode stored? Is it in some on-chip ROM?
      - Pica_soO 9y ago
        You got me, hat tip. Look Up Tables :D
rjsw 9y ago
The TMS34010 wasn't RISC by any normal definition. It was nice though, I wrote a backend for GNU binutils for it and wrote an X11 driver for the chip.
- waynecochran 9y ago
  I guess I mean RISC in the sense that it had a small set of orthogonal instructions, a large set if general purpose registers, and non-move instructions required operands to be in registers. Very simple and clean model from the programmers perspective.
gp2000 9y ago
You could choose that the memory accesses be at any bit size from 1 to 32 with both unsigned and sign-extended register loads. In fact, I think you got to pick two sizes and for most normal operation you'd choose 16 and 32 bits. There were some load/store operations that always operated at 8 bits so you'd get the usual complement of data sizes. Pretty useful feature for something that was intended to be a graphics processor. I've also seen the different bit sizes used for fast and simple Huffman decoding in gzip decompression. The auto-increment/decrement addressing modes were aware of the bit size. Thus you could have polymorphic subroutines where the same code could be used to sum an array of bytes, words, 13 bit quantities or whatever size word you wanted (up to 32 bits). Since the processor had built-in circuitry to help drive graphics displays it took a high input frequency of something like 40 or 50 MHz and actually divided that down to run the processor at around 10 MHz or so. The opposite of what we're used to now and made the darn things look scary (well, scarier) from an emulation programmer's perspective. The memory interface was designed to work with shift-register VRAM. The idea there being that the VRAM chips had a built-in shift register 512 pixels wide. The display circuitry would make use of it by having each line from the frame buffer dumped into the shift register as the raster was moving down the screen. And then the shift register would clock out the pixels as the raster moved across each line. During VBLANK (when the video circuitry is waiting for the raster to return to the top of the screen) you could use special instructions to load and store the shift register which would be as fast as any load/store operation. The entire frame buffer could be filled very quickly with any repetitive pattern or erased entirely by copying some fixed line to all the others. Lotta cool stuff in that beast.
- waynecochran 9y ago
  Yes and then the TMS34020 came out which had a trapezoid fill instruction. Essentially you would partition your polygon into trapezoids; For each trapezoid you would load the appropriate registers ... the slopes of the edges used 16.16 fixed point numbers. I remember how much you could do with fixed point arithmetic.. very few programmers even know how program using fixed point anymore. A very useful lost art. There was also a built in Bressenhsm line drawing instruction. Then there was the TMS34082 floating point coprocessor. I essentially wrote a primitive OpenGL'ish pipeline API. That was fun. Wow... I really wish a general purpose processor like this made it into the PC. The best stuff doesn't always win in the marketplace.
amelius 9y ago
> I blame the general aversion for assembly programming to the choice of using the 8086 for PC's. Well, nowadays you can use LLVM instead and achieve portability, at perhaps a small cost in efficiency.
- waynecochran 9y ago
  The problem with writing LLVM is that you must use Static Single Assignment (SSA) to the pseudo-registers. If I had the time I'd like to write non-SSA LLVM assembler that transpiled into SSA for you.

dreamcompiler 9y ago

The 34010 was indeed a sweet chip. I once wrote a Forth compiler for it in assembler as an exercise. Coding graphics in Forth was a joy. And yes, Intel's instruction sets are so butt-ugly they make everybody else's look beautiful by comparison. I really wish almost any other chip had won the war for that reason. I'm encouraged by the rising profile of ARM.

megablast 9y ago

> I blame the general aversion for assembly programming to the choice of using the 8086 for PC's. I loved 8086 assembly after coming from Z80. And one of the reasons it was so fast was because of minimal registers. And 8086 was released 10 years earlier.

joezydeco 9y ago

If you played any of the Williams Electronics or Midway arcade titles from the late 1980s through the mid-90s (NARC, Smash TV, Cruis'n USA/World, Mortal Kombat 1/2/3, Terminator 2, NBA Jam, etc) they were all done on the TMS34010 or 32031...all in assembly language.

gp2000 9y ago
Emulation of that processor was a bit of a challenge. Fortunately the fully general bit addressibility was only used in gzip decompression and the drawing instructions (circles, rectangles, that sort of thing) only came up in test mode. So not all of it had to be implemented and only the normal 8/16/32 bit addressing modes had to be fast.

pjmlp 9y ago

Not everyone hates x86. I had lots of fun coding for with, initially with as86 and then TASM. The only thing I hated with the x86 was trying to use AT&T syntax a few decades later. I also coded for Z80, 68000 and MIPS.

waynecochran 9y ago
I have learned three different syntaxes for the same x86 instruction set: [MBTN]ASM (DOS/WIN16/32), GNU assembly, and Amsterdam compiler kit (Minix). All of them used different mnemonics, a different notation for addressing, and couldn't decide between MOV SRC,DST and MOV DST,SRC. Then you had real mode vs protected mode which used the same segmented registers in a completely different way -- a clever way to be backwards compatible -- long story. In real mode you have a variety of different memory models: tiny, small, large, ... -- near and far ptrs? -- ugh. 20-bit physical addresses from segment << 4 | offset. Uggggllllyyyyy.... Forget about the x87 floating point processor -- arguments go on a 8-level deep stack -- really? I got to push and pop to do floating point? Now you have AMD-64. But all that old stuff is still there taking up transistors!
- Pica_soO 9y ago
  Not really.. the API is still there, behaving like a backwards compatible processor, but deep down- there is no reserved silicon for this- just pipelines, getting microcode.
  - waynecochran 9y ago
    Naive architecture question: where is the microcode stored? Is it in some on-chip ROM?
    - Pica_soO 9y ago
      You got me, hat tip. Look Up Tables :D

rjsw 9y ago

The TMS34010 wasn't RISC by any normal definition. It was nice though, I wrote a backend for GNU binutils for it and wrote an X11 driver for the chip.

waynecochran 9y ago
I guess I mean RISC in the sense that it had a small set of orthogonal instructions, a large set if general purpose registers, and non-move instructions required operands to be in registers. Very simple and clean model from the programmers perspective.

gp2000 9y ago

You could choose that the memory accesses be at any bit size from 1 to 32 with both unsigned and sign-extended register loads. In fact, I think you got to pick two sizes and for most normal operation you'd choose 16 and 32 bits. There were some load/store operations that always operated at 8 bits so you'd get the usual complement of data sizes. Pretty useful feature for something that was intended to be a graphics processor. I've also seen the different bit sizes used for fast and simple Huffman decoding in gzip decompression. The auto-increment/decrement addressing modes were aware of the bit size. Thus you could have polymorphic subroutines where the same code could be used to sum an array of bytes, words, 13 bit quantities or whatever size word you wanted (up to 32 bits). Since the processor had built-in circuitry to help drive graphics displays it took a high input frequency of something like 40 or 50 MHz and actually divided that down to run the processor at around 10 MHz or so. The opposite of what we're used to now and made the darn things look scary (well, scarier) from an emulation programmer's perspective. The memory interface was designed to work with shift-register VRAM. The idea there being that the VRAM chips had a built-in shift register 512 pixels wide. The display circuitry would make use of it by having each line from the frame buffer dumped into the shift register as the raster was moving down the screen. And then the shift register would clock out the pixels as the raster moved across each line. During VBLANK (when the video circuitry is waiting for the raster to return to the top of the screen) you could use special instructions to load and store the shift register which would be as fast as any load/store operation. The entire frame buffer could be filled very quickly with any repetitive pattern or erased entirely by copying some fixed line to all the others. Lotta cool stuff in that beast.

waynecochran 9y ago
Yes and then the TMS34020 came out which had a trapezoid fill instruction. Essentially you would partition your polygon into trapezoids; For each trapezoid you would load the appropriate registers ... the slopes of the edges used 16.16 fixed point numbers. I remember how much you could do with fixed point arithmetic.. very few programmers even know how program using fixed point anymore. A very useful lost art. There was also a built in Bressenhsm line drawing instruction. Then there was the TMS34082 floating point coprocessor. I essentially wrote a primitive OpenGL'ish pipeline API. That was fun. Wow... I really wish a general purpose processor like this made it into the PC. The best stuff doesn't always win in the marketplace.

amelius 9y ago

> I blame the general aversion for assembly programming to the choice of using the 8086 for PC's. Well, nowadays you can use LLVM instead and achieve portability, at perhaps a small cost in efficiency.

waynecochran 9y ago
The problem with writing LLVM is that you must use Static Single Assignment (SSA) to the pseudo-registers. If I had the time I'd like to write non-SSA LLVM assembler that transpiled into SSA for you.