Talk:Texas Instruments TMS9900
the page is full of speculation and inaccurate information. coming from someone who owned nearly every micro-processor available in 1978 - 1988 and memorized their instruction sets.
just some examples:
- the processor is big endian in that the low order address bit, A15 (which did no appear on the address pins of the chip) addressed the rightmost byte of a 16 bit word if 0, and addressed the leftmost byte of a 16 bit word if 1. (and yes, it is confusing at first that TI choose the pin numbers not as 2^N, but as A0=high and A15=low. Same for D0-D15.
- the instruction set is nearly a complete ripoff of the PDP 11, but with 4 bits of register addressing.
- the AMD 2901 bit-slice and the National Bit-slice chips are not "microprocessors", they are bit-slice, which meant that any processor built with them was multi-chip by nature (ALU, Instruction decode, address/data buss management were separate chips)
- the IBM-PC team in Boca Raton seriously consider the TMS9900 for the original PC, but decided on the 8088 based on a variety of reasons including production costs.
- the TMS9900 was one of very few microprocessors which was available in a radiation hardened version, and it became popular in military hardware for guidance and control systems for missiles and aircraft.
- I have serious reservations about the statement someone made that "every illegal opcode executes as a NOP" ... that does not agree with my personal experience with the processors used in the TI-99 and the later MyARC Geneve (TMS 9995). There were undocumented instructions in various production runs, and they had various side-effects. One which comes to mind is a buggy and incomplete implemention of MPY (multiply) which was on a 1985 production TMS 9900.
- I don't understand someone's reference to "distributed computing" in the context of the X (eXecute) instruction. It was useful for debugging and for creating an indexed-opcode table used in a byte-code interpreter. Typical form was "X @BASE+INDEX". The drawback I recall is that the 2nd word (if needed) when the instruction was decoded was pulled from after the X instruction, not from after the target of the X instruction. My recollection may be faulty -- I need to reread the instruction datasheet.
- discussion below, regarding RSET, LREX, etc. yes, they drove the 3 HIGH order address PINS in a non-memory address cycle along with CRUCLK. If there was no external hardware to detect the non-memory address cycle, then nothing special happened, and the instructions only vectored as documented.
Curious about X
The main article says there was a rare and uncommon instruction called "X" - used for executing an instruction that is pointed to, by another register. After the instruction, program flow resumes where the Program Counter used to be.
What is the object code for this instruction?
The main article could be improved by explaining which engineers came up with this instruction. Its probable use appears to be fairly obvious. It appears to facilitate distributed processing.
- Execute instructions were well known. The IBM System/360 and DEC PDP-6 and -10 both had them, as did the Varian 620 mini John L (talk) 03:19, 23 August 2009 (UTC)
- The 360 version of this instruction was called EX, and it ORed some data from a register into the instruction before executing it. I can't find the equivalent instruction in the PDP-10 opcode charts. Some guy in a forum explained that, for the 360, "So you normaly use the EX to modify the length of a mvc,clc,pack,ap or sp instruction." Some other guy somewhere said, "This allows you do a MVC where the length is not known until run time, like the length of your PARM field." (I believe those instructions include a string length in bytes in the instruction itself.)
- Another use for the EX instruction on the 360 is apparently to generate a program crash ("abend") by trying to EX an EX.
- According to a chapter I found online with the TMS 9900 instruction set, the X instruction was encoded with the opcode 0 0 0 0 0 1 0 0 1 0, followed by two bits of TS and four bits of S. It says that the instruction executed is "the instruction at SA", but I'm not clear what SA is; perhaps S names a register, and the register points at the instruction in memory.
- So it appears that the primary use of instructions like this was to work around (what I would consider) serious brain damage in the rest of the instruction set without actually needing to generate new code in memory.
- My original thought was that EX would be a useful instruction for writing a debugger that could single-step machine code, but I can't find any indication that people used it for that. But I guess you don't need to write debuggers as often as you need to copy around variable-length strings.
- None of this has anything to do with distributed processing. If you want to ship some mobile code across a network, which is maybe what you were thinking of, you probably want to ship more than one instruction at a time. In that case you'd just call it like any other subroutine. Kragen Javier Sitaker (talk) 03:14, 4 March 2011 (UTC)
Without having to download and study the TMS9900 instruction set, can anybody brief me on what the RSET instruction did? Was it a software interrupt like the 6502 BRK, but uninterruptible, like an NMI triggered by software?
The main article could be improved by describing the RSET instruction, and noting whether it could bring about a restart, or was it more like a "clear" the bit instruction, similar to RCLR in some microprocessors like the 68000? 220.127.116.11 (talk) 23:12, 6 September 2009 (UTC)
- The book "Fundamentals of TI-99/4A Assembly Language" helps answer this question on page 303. RSET is a control instruction, just like LREX, CKOF, CKON, IDLE, and CRU. The last operation is apparently a hardware operation realized by accessing a particular address in memory without an opcode. That doesn't make sense to me, so maybe someone here at Wiki can explain it, as the only thing that is important is driving the bottom 3 address lines, perhaps by inserting a cartridge that grounds those lines, or raises them up somehow.
- If it is helpful, the opcodes are defined in binary as:
- RSET ($0360) %0000 0011 0110 0000
- IDLE ($0340) %0000 0011 0100 0000
- LREX ($03E0) %0000 0011 1110 0000
- CKOF ($03C0) %0000 0011 1100 0000
- CKON ($03A0) %0000 0011 0110 0000
- If the object code looks a little funny to you, or doesn't add up, remember that this is a Big Endian microprocessor. 18.104.22.168 (talk) —Preceding undated comment added 07:22, 9 September 2009 (UTC).
- Whenever a control opcode (listed above) is executed, it apparently affects the bottom3 address lines (bits A0, A1, A2). Since this is a Big Endian microprocessor, am I right in concluding this brings about a massive memory shift? Where the 3 bottom bits are actually the 3 highest bits of addressable memory? Sort of like swapping out entire chunks of addressable memory? 22.214.171.124 (talk) 07:44, 10 September 2009 (UTC)
- It isn't immediately clear to me that the microprocessor is Big Endian. But it is 16 bits wide, so the opcodes are 16 bits wide, that much is clear. But whether the opcode for RSET is stored in memory as $03 followed by $60, or $60 followed by $03, is a question that hasn't been answered so far; depending on the way the question is answered, determines whether the microprocessor is Big Endian or not. —Preceding unsigned comment added by 126.96.36.199 (talk) 03:39, 13 September 2009 (UTC)
Endianness is one of the most misunderstood things among software developers. The reason is that people get hung up on terminology and lose sight of what is really happening at the hardware level.
First, the TMS9900 is a Big Endian processor. Which bit is called A0 has nothing to do with endianness. There does seem to be some consistency among chip manufacturers regarding this labeling, but that is merely coincidental. For the TMS9900, TI chose A0 to represent the most significant address bit and A14 to be the least significant address bit. They could have labeled them in the reverse order without changing the endianness.
Second, when a RSET instruction executes, the 3 most significant address lines (A0, A1, and A2) are driven Low, High, High, respectively, and the CRUCLK line is pulsed. This combination of signals causes the CRU bus to reset, but does not invoke a memory access. Then the 9900 loads the contents of memory at address 0000 into the Workspace Pointer (WP) register and address 0002 is loaded into the program counter (PC). After this, execution continues at the address loaded into the PC.
If you look at the object code on a Little Endian computer (such as a PC), the RSET instruction may look like 60 03, but on a big endian machine (or with SW that compensates for endianness) you would see 03 60. Because the 9900 is a 16 bit device, the opcode is stored in memory as 0360. Jimwilliams57 (talk) 05:09, 14 September 2009 (UTC)
You should keep in mind that the so called external instructions, with the mnemonics LREX, RSET, CKON, CKOF and IDLE have their names from their use in the TM 990 mini computers. In addition to their meaning inside the CPU, their full function relies on specific hardware to decode these instructions. What happens when they are executed depends upon that hardware. It is for example possible to include hardware that will decode the RSET instruction to also do a hardware reset of chips in the computer, including the CPU itself. Without such hardware, the only thing that happens is that the CPU disables interrupts, by loading zeroes into ST12-ST15, which is equivalent to executing LIMI 0. The IDLE instruction could turn on an indicator LED, to tell the user the CPU is idle (as was done by the Cortex computer). That computer also took benefit from the CKON and CKOF instructions, but used them to enable and disable a memory mapper circuitry. LREX cause a delayed interrupt after two instructions, by clocking a row of flip-flops with the IAQ signal. By loading proper values into R13-R15, then executing LREX RTWP, the computer would "return" to the desired instruction, execute that one, then come back to a debugger by the interrupt.
There's a neutrality disputed tag on the main page, but no discussion of neutrality in the talk page - what's up? At first reading, the article feels like it's been written by an enthusiast of the chip, but it doesn't seem wildly at variance with NPOV. Rob Burbidge (talk) 12:16, 16 September 2009 (UTC)
- I believe the issue lies with the fact that there aren't any references cited whatsoever. Which is why you would put a citations needed notice...Most or all of what is said is true, but without citing sources or going into detail, one could dispute the neutrality. For instance, the claim about how it "had the potential to surpass the 8086." It does strike me as rather bad taste to add that "neutrality disputed" notice without any talk. Since there's no talk, I think it should be replaced with a "lacks citation" notices, unless anyone wants to raise any real objections... Sidenote, the citation needed/lacks verification notices are getting far too annoying all over Wikipedia; it seems every other article I look at (I mostly browse technical articles) has them. Sigh. Citations are often just a google away.. pokeme444 (talk) 6:52, 4 May 2010 (UTC)
what is the problem?
what is the neutrality issue? whoever initiated the claim should at least discuss it, or remove it. it is distracting .
also, the list of 'inaccuracies' is really a list of statements, mostly not even addressing any inaccuracies in the article. i don't understand point 2, the 'ripoff' statement. the opcodes are NOT the same as the PDP11. eg; mov is 001 for the PDP, but 110 in the TMS. similarly, 010/100 for com, 011/110 for subtract, etc.