15

Reading over the design of the TMS9900 it is often claimed that the R0 - R15 registers are in RAM because semiconductor RAM ran at the same speed as the CPU and therefore there was no penalty to doing so - as well as obvious advantages in context switching and so forth.

But unless I'm missing something, this statement seems wrong. I do not see any specialized access lines to memory for the registers, so I assume a normal memory read is required. That would normally be >0 cycles and have to be latched internally, no?

Is there something I'm missing here? Cycle stealing perhaps?

2
  • I remember programming for this CPU back in Sep. 1982. Forever ago. – President James K. Polk May 28 at 1:27
  • I never programmed a TI-9900, but I remember it coming out. The advantage of the register pointer is that you could switch contexts very fast (I don't remember, was there an instruction to copy the registers to a new location or some other quick way of doing that?). If you got an interrupt, you could just use a new register set, and then, when you returned, go back to the old set. – Flydog57 May 29 at 1:33
20

The TMS9900 only has 3 real registers (in the sense of being on the CPU) - PC, ST, and WP. (It didn't even have a stack pointer, the branching works a lot like MIPS with the "Branch and Link" and you have to implement a stack yourself if you want it).

WP points to a memory location in RAM.

The 16 "general purpose user registers" are in reality 32 bytes of RAM (2 8-bit bytes per register) starting at WP and in the same RAM that everything else uses. Loads and stores at these locations will modify the general purpose "registers".

TMS9900 is from the age where CPU and RAM were the same MHz and there were no wait states, or cache. So this was OK at the time.

The 6502 had register-minimalism as well (1 accumulator, 2 index registrers, and the concept of "zero-page" addressing modes that allowed the first 256 bytes of RAM to be used as pointers).

6
  • 3
    "no wait states, or cache" - but the read itself still takes time no? The data has to come in over the pins, whereas with an internal register you have custom wiring right to the latches. – Maury Markowitz May 26 at 17:50
  • @MauryMarkowitz: I'm not familiar with how things are implemented in that particular machine, but if e.g. the ALU would take 2.5 cycles to perform a computation, and the same ALU is used to increment the program counter as for other purposes, that would yield a minimum instruction time of six cycles if using internal registers, but could achieve an instruction time of eight cycles when using external registers if during the processing of each instruction the next instruction is fetched between the second "register" read and the "register" write. So the use of memory for registers... – supercat May 26 at 20:27
  • ...would impose a speed penalty, but a relatively mild one given the facilitated savings in cost compared with having to hold 16 registers. If the ALU were faster, it could be useful to add a 16x17 RAM for the sixteen registers (including a "valid" bit for each register) and have writes go to both that RAM and to external memory, while reads would be processed from that RAM if it's valid. I wouldn't be surprised, though, if the ALU speed would limit the performance boost to about 25%, which may not be worth the cost. – supercat May 26 at 20:30
  • 1
    I'm not sure this answers the question? "I do not see any specialized access lines to memory for the registers, so I assume a normal memory read is required. That would normally be >0 cycles and have to be latched internally, no?" – OmarL May 27 at 9:04
  • 1
    @LawrenceC, The CPU will not do the same exact operations, because MOV R2, R0 needs to load R2 from the workspace, but LI R0, 0FFFFh loads it from the instruction stream. Compare MOV R2, R0 with the 6502 TAX or Z80 LD B,A, which do not need a memory cycle to fetch the A register. – OmarL May 27 at 20:41
18

Reading over the design of the TMS9900 it is often claimed that the R0 - R15 registers are in RAM because semiconductor RAM ran at the same speed as the CPU and therefore there was no penalty to doing so

But unless I'm missing something, this statement seems wrong.

Why?

I do not see any specialized access lines to memory for the registers, so I assume a normal memory read is required.

Jup, so it is, (usually) every other cycle is a memory cycle.

That would normally be >0 cycles and have to be latched internally, no?

Jup, and?

Is there something I'm missing here? Cycle stealing perhaps?

No, except that cycle and speed is kind of an arbitrary concept, used different in each designer/team. This starts by what one does call a cycle, and how internal cycles are seen from the outside. Just take the 8080 and its concept of machine and clock cycles.

Or our beloved 6502. A 1 MHz 6502 runs at 1 MHz, right? No, it runs at 2 MHz! It does two internal cycles per external clock. It's always an internal cycle (ALU cycle) followed by a memory cycle (*1)

The 9900 works quite similar, here as well each other machine cycle is a memory cycle. Except that each of these machine cycles last two clock cycles. Let's look at a typical instruction, adding two register:

(this will be rather simplified for in detail description you may want to consult the manual)

A R1,R2

    1. Memory: Read instruction
    1. Internal: Decode Instruction
    1. Memory: Read R1
    1. Internal: Setup addition
    1. Memory: Read R2
    1. Internal: Add
    1. Memory: Write R1

So this addition takes 7 machine or 14 clock cycles. It does sound like an awful wast of cycles, right?

So, how does a 6502 do it?

  • For a fair comparison we look at each half clock cycle separate.
  • In addition we use a ZP instruction to make it a fair one.
  • We ignore as well istruction differences and simply assume a 6502 ADC is the same as a 9900 A. But most of all
  • We ignore the 16 bit nature of the 9900, after all, there could have been a 6516 with 16 bit data bus as well (*2)

ADC zploc

  • 1.1 Internal: Housekeeping for the last instruction
  • 1.2 Memory: Fetch OP
  • 2.1 Internal: Increment PC, Decode OP
  • 2.2 Memory: Fetch ZP-address
  • 3.1 Internal: Increment PC
  • 3.2 Memory: Fetch data from ZP
  • 4.1 Internal: Add and settle result in A

Since the first half cycle belongs to the previous instruction, we come down to 6 steps taken (albeit not having written back to memory at all) and only 3 'real' cycles, isn't that great? And quite fast?

Now, serious, cycles are Hokus Pokus, terms design magicians pull out of their hats to impress the audience. When looking behind that facade, all that really exists are are memory cycles - which as well is the start of the argument: memory speed

So let's assume we use 500 ns RAM (*3) with the above CPUs_

  • Doing the 6 machine cycles of a 6502 will take 3 µs, while only half the bandwidth of the memory is used.
  • Doing the 7 machine cycles of a 9900 will take 3.5 µs, using a bit less than half of that for memory access.

It's exactly the pipelining half cycle the 6502 is faster for such simple cases. Except, the 9900 has already used that time to write back the data to memory as well (*4)

It will get better with more complex instructions, as the 9900 can have several internal cycles in sequence, whereas the 6502 always has to do a memory cycle as well (*4) - nicely shown with page crossing indexing.


Long story short: Never look at fancy clock rates, but focus on memory timing when comparing CPUs


But, but ...

... couldn't the CPU have been much faster with registers on chip?

Yes, it could, but what for? It would have cost a lot of real estate - 16 registers with 16 bits are 256 bits. With addressing logic this cones down anywhere between 1000 and 2000 transistors - quite some dough back then. Why invest that? Sure, taking above scheme, it may have speed up the execution from 14 to maybe 8 clocks, while doubling the price? (*5)

Not to mention that putting them on chi will introduce all the overhead of register saving - something eating up many instructions and memory cycles with other machines.

And finally there is the historic part - the 9900 is the single chip implementation of the way older 990, designed at at time when memory was not only expensive, but transistors even more rare.


*1 - And when looking really close we even see 4 cycles, as each edge of each phase is used to trigger certain workings.

*2 - No I will not go down that hole of describing all the pitfalls of such a CPU.

*3 - For this we ignore all the fine print about memory selection and simply say we have a memory that delivers a word within 500 ns.

*4 - The burden the simplified memory interface brings.

*5 - Price increase isn't linear. It's safe to assume that a 9900 was already close to what could be made economic in 1976. Increasing that by 15-25% would have for sure resulted in a way higher cost than those percentage.

7
  • 2
    The original TI 990 minicomputer was designed as an industrial process control machine, where low interrupt latency was important, and there were 256 real-time interrupt levels, but there wasn't a need for a lot of CPU power. The registers-in-ram design meant that there was no need to save a lot of data out to RAM when responding to an interrupt. – John Dallman May 27 at 19:52
  • 1
    @JohnDallman true. Then again, having registers in RAM was quite common with designs way into the 70s. This includes not just specialized (control) minis but business computers (like Dietz) all the way to mainframes, including /360 models. – Raffzahn May 27 at 20:30
  • While the 6502 doesn't "need" the memory bus during the first half of each cycle, it outputs the memory address for each cycle very early in phase 1, so a 1MHz 6502 could probably get by with a RAM access time of over 750ns if it didn't have to share the bus with something like a video subsystem. – supercat May 28 at 22:11
  • So the TL:DR: here is that the "no penalty" claim is basically bogus. If you interpret the claim as "no speed penalty compared to having registers on chip", then it would have sped up each instruction significantly. Not that it would have been worth spending that many transistors, but it was a justifiable tradeoff, not a pure win / no penalty situation. Just "not a disaster" like it would be in a modern system that needs cache to insulate the CPU from slow RAM. (Or there are other ways to parse the claim, I guess; Bruce's answer proposes a reasonable argument for "no penalty") – Peter Cordes May 29 at 21:37
  • @PeterCordes sorry, but even after reading it a third and fourth time, I do not understand what you try to point out. One can always throw more hardware on a problem to allow faster operation. But that never stays on it's own. Of course one can (in NMOS) build a register file with multiple read and write ports that allow an addition between two registers in a single step. Any win or penalty is always in relation to the effort and goals to reach. Building a commercial CPU isn't a race for the fastest - not back then and not now - speed is only one design goal, often the least important – Raffzahn May 30 at 1:16
10

I do not see any specialized access lines to memory for the registers, so I assume a normal memory read is required. That would normally be >0 cycles and have to be latched internally, no?

The TMS9900 effectively extends its internal bus out to external memory, so no extra latching or cycling is required. Theoretically if it internalized the 'registers' they could be accessed faster because the CPU wouldn't have to cycle the external memory bus, but it still has to cycle its internal 'register' bus. If the internal bus is no faster than the external bus and they can't operate in parallel then there is little advantage to having internal registers.

The TMS9900 used an early NMOS process that is not capable of very high speed internal operation, and low transistor density so to squeeze in a large array of internal registers on a separate internal bus it would have to compromise in other areas. It could have had fewer internal registers but they would need more external bus cycles to keep them fed, so overall throughput could actually be slower. Having a 'workspace' with direct 'register-like' access makes the instruction set more orthogonal and perhaps more efficient. The TMS9900 can place its workspace anywhere in memory via its 'WP' pointer register. This can be used for efficient context switching or just to eliminate the limitations of a fixed 'zero page' memory space as used in the 6800 and 6502.

The TMS9900 is a bit odd compared to most contemporary CPUs, but once you get over peculiarities such as the reversed address bus labeling etc. it's not that bad. However its implementation in the Ti99/4A was atrocious. Texas Instruments apparently didn't grasp the implications of Moore's Law because they only gave it 256 bytes of 16 bit RAM and a slow 8 bit memory expansion bus. This was doubly bad because the CPU always accesses the RAM in 16 bit words, which means it has to do 2 read cycles and 2 write cycles for every 8 bit write.

Even worse, the 'RAM' in a stock Ti99/4A is actually video memory which is on the other side of the TMS9918 display controller, and can only be accessed sequentially one byte at a time through its (slow) I/O port. They used a similar system for their 'GROM' (Graphic Read Only Memory) cartridges, which are fine for storing Byte code or BASIC programs that are interpreted, but useless for machine code.

The TMS9900 is essentially nobbled in the Ti99/4A, and doesn't reach its full potential unless true 16 bit RAM is installed - which is possible but requires a lot of hardware hacking on the motherboard. Once this is done it can run code from main memory at least twice as fast, with an average 50-60% faster operation for programs that use the system.

7
  • 3
    True, but there is a long history of mismanagement and big company politics that did lead to this less then great design. Hard to blame the engineers. They delivered best possible in that situation, more than i'd believe any other team would have. Heck,eventhe fact that two8 bit access cycles are done to fetch an 8 bit value from an 8 bit device is the result of management decision, not engineering. The hardware could have done a single cycle, but they were not allowed to modify that. Then again, I think the 99/4 is not part of the question, or is it? – Raffzahn May 27 at 1:38
  • I'm not blaming the engineers. No doubt they wanted it to have true 16 bit RAM etc., but management couldn't see that RAM would soon be cheap enough to allow it. They ended up selling it below cost anyway to compete with the C64 (another machine that was compromised by the urgent need to get it out now! before the market disappeared. In the end the 'least worst' machine won). – Bruce Abbott May 27 at 1:46
  • The TMS9900's use in the ti99/4 and 99/4A is not mentioned in the question, but that was its only(?) commercial application that people are familiar with and may color their perception of its performance. so I think it's fair to point out that it can do better in a well designed system. – Bruce Abbott May 27 at 2:00
  • TI-99/4 architecture was hobbled together because the embedded department failed to deliver the promised 9980 in time. If it had been, it would have been a real nice machine for 1979. – Patrick Schlüter May 27 at 7:49
  • @BruceAbbott & Patrick The story is a bit more complex than 'real RAM' and 'missing Embedded CPU' and mostly based on meta decisions. Short version: Originally 3 developments were initiated: a Game Console, a Home Computer and a Professional Desktop system. 3 independent teams were set up. All three usingdifferent level of 9900 CPUs. After intervention of the mini computer department, that the professional system would belong to their 'sphere', that team got merged - were the project was underfunded and essentially put in development hell by the basic mindset that 'if users want a ... 1/2 – Raffzahn May 27 at 12:41
7

TMS-9900 was the on one chip implementation of the TMS-990 mini-computer architecture. The TMS-990 mini-computer were built from discrete TTL chips before the advent of big solid state single dynamic RAM chips. In that context, memory access and register access were strictly speaking exactly the same thing. It is only later with higher integration that the speed discrepancy between on-chip and off-chip access time started to grow, making the TMS-990 approach not viable (only some embedded Harvard micro-controller architecture continued with addressable memory/register system for their internal memory like microchip, AVR or more esoteric Z8 and Sharp SH-61860).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.