Musings on 99000 macro code

[jbdigriz]

1 hour ago, dhe said:

So, yea for dfm - it started on the 990's and of course is very similar to TI-Writer/Editor Assembler editors.

I think you have the heritage of later versions of dfm figured out, Gleen took it and made it available for TI and later HPUX systems along with ISAMATION.

Larry Kroeker made a PC version available, at one point, I think Larry had a proto-windows version going.

I also think Larry has passed.

I did see an obit notice for a Larry Kroeker in McKinney, TX ca. 2011. Didn't see the full obit.

1 hour ago, dhe said:

In the past, TI was very pragmatic about licensing. So I imagine it was as easy as say Larry talking to someone in management along the lines of:

   Larry: Do you have any plans of selling dfm in the PC market.

   TI: No

   Larry: Do you mind if I do?

   TI: No, but we get 2% royalties and maintain our original copyright.

Tallies with what I've heard. Still want to nail down what ISSS was, but that's going on the stack for now. I'll be interested to follow Robert's take on DF-[SHOW,EDIT]  for modern OSes. He may be interested to know that 990 dfm supported tape files and encryption. I don't know if any of the DOS versions did. He may want to take a look at Midnight Commander, too, which bears a lot of DOS influences, possibly DF-EDIT and SHOW included. Looks like maybe he's following up an elder relation's project here? Wish him well with it, and maybe it will bear fruit with a new DOS or Windows version as well. Lot of people building retro DOS boxes these days. 

[Michael Anderson]

Strange that the Ten-X cobol accelerator would be discussed this late in Time.  That was my father's (Andy Anderson) and Freddie Walker's idea.  They got financing for the start up from friends and associates of another partner they picked up in the development Darren Appelt.  Ten-X is still around but reformed into another company named Ten-x precision.  Darren Appelt in my view would not be the best contact for questions about the Ten-X cobol accelerator.  Mark Gentry in Austin I think eventually became head of engineering at Ten-X to my understanding.  I can come up with his contact info if needed.  Michael Anderson

[jbdigriz]

On 12/6/2021 at 5:25 AM, Michael Anderson said:

Strange that the Ten-X cobol accelerator would be discussed this late in Time.  That was my father's (Andy Anderson) and Freddie Walker's idea.  They got financing for the start up from friends and associates of another partner they picked up in the development Darren Appelt.  Ten-X is still around but reformed into another company named Ten-x precision.  Darren Appelt in my view would not be the best contact for questions about the Ten-X cobol accelerator.  Mark Gentry in Austin I think eventually became head of engineering at Ten-X to my understanding.  I can come up with his contact info if needed.  Michael Anderson

Sorry I missed this till now, Michael. Appreciate the info!

[Ex-TI]

On 1/18/2018 at 9:26 AM, pnr said:

Hi,

 

Many thanks for that link! It explains why sometimes TI marketing documents refer to the 99120 as having the "Rx kernel" in macro rom and sometimes as having Pascal support instructions in it. In TI's vision for Microprocessor Pascal the two are closely linked topics.

 

 

This would be the manual "990/12 Writeable Control Store Assembler and Language". It describes the details of microprogramming a TI990/12, I understand. As the 990/12 was released in 1979, I would assume that this manual also dates from 1979, possibly with later revisions.

Did you ever locate the Writable Control Store manual?  I worked on that in the 80's and would love a copy.

[pnr2015]

On 1/24/2022 at 9:56 PM, Ex-TI said:

Did you ever locate the Writable Control Store manual?  I worked on that in the 80's and would love a copy.

Sorry for the delay in answering, but no, I have never found a copy of that manual. It must have had pretty limited circulation for no copy to survive. Micro-programming was (and is) a highly specialised occupation, I suppose. 

[apersson850]

7 hours ago, pnr2015 said:

Micro-programming was (and is) a highly specialised occupation, I suppose. 

I did it for a couple of processors back at school, but only then. So I concur.

[+FarmerPotato]

17 hours ago, pnr2015 said:

Sorry for the delay in answering, but no, I have never found a copy of that manual. It must have had pretty limited circulation for no copy to survive.

 

I found one title listed in the 1983 accession to the TI Archive, now at DeGolyer Library, SMU:

 

Model 990 Computer MDS990 Microcode Development System Programmer's Guide  2264445-9701

(Also, the stack location / box number.)

 

 I see  it referenced in the 990/12 Assembly Language Programmer's Guide.  
 

 

 

 

17 hours ago, pnr2015 said:

Micro-programming was (and is) a highly specialised occupation, I suppose

At the VCFSW event, I heard a talk on 6809 micro-architecture. The speaker recommended a 1993 textbook, "Microprogrammed State Machine Design". It is pricey.

 

 https://www.routledge.com/Microprogrammed-State-Machine-Design/Lynch/p/book/9780849344640
 

 

 

[apersson850]

I've written microcode for a bit-slice processor based on the very popular Am2900 series of components (Advanced Micro Devices).

The last CPU I wrote microcode for was the DSK 86000, a specialized two-chip CPU for robotics control. The microcode word was 80 bits wide, as far as I remember, in that one.

[+TheBF]

3 hours ago, apersson850 said:

I've written microcode for a bit-slice processor based on the very popular Am2900 series of components (Advanced Micro Devices).

The last CPU I wrote microcode for was the DSK 86000, a specialized two-chip CPU for robotics control. The microcode word was 80 bits wide, as far as I remember, in that one.

I have no experience with this at all.

What is a development system like for microcode?

Is there an instruction set?

How many instructions are in the set? 

[apersson850]

It's kind of the other way around, compared to using assembly (machine) language.

When you use assembly language you don't have too many bits (16 in the 9900) to define you instructions. But they can do powerful things, like MPY and BLWP, to take some of the more complex instructions supported by the TMS 9900.

 

When you do microprogramming you have far less advanced instructions available. If you build your CPU with AMD 2900 slices you have the different instructions the ALU can do, but that's not very much. On the other hand you typically have a much wider instruction word (like 80 bits in one system I programmed), where each bit can control for example setting/clearing a flag, moving a value from one register to another, shift a bit pattern to the left or the right, control if carry should propagate to the next bit, test a value against zero, test a value against another value, make the sequencer jump in the microcode unconditionally or based on a test...

 

What you try to do with the hardware architecture you have at hand is to figure out how many things you can possibly do at the same time, to make assembly instructions run in as few clock cycles as possible. Like read one value from memory, read the next value from memory and then read the next instruction from memory at the same time as you add the two values, since the ALU will not need to do a memory access to add the two values, then write the result back to memory at the same time as you decode the instruction you just read in and so on. Clever use of as much parallel hardware as possible will speed up your CPU.

 

That special robotics controller I was involved in did have an instruction set adapted to the special needs of robotics. Coordinate conversions are common, so it did for example support sine and cosine for 32-bit floating point numbers directly in assembly language. It also had a register file where you could do something similar to BLWP, but the subroutine call shifted the 16 register workspace 12 positions in the register file. Thus if you called a subroutine in high level language (Pascal at that time) with no more than four parameters, they were stored in R12-R15 and when the call was done, they were in the new R0-R3. Results could easily be returned without having to push everything on a stack. Multiple efficient subroutines were possible, as long as you didn't run out of the register file. Returning from the subroutine shifted the registers back, so the results now appeared in R12-R15.

[+TheBF]

Very very interesting. Thanks.

 

Was the 80 bit machine considered VLIW ? (very large instruction word) I had read about those in US military projects or some such thing 40 years ago. 

 

I have encountered something like this before in my reading. 

This bit slicing was used by Chuck Moore in his CPUs. 

They were only 16 bit machines but since the "registers" were actually the data stack there were no bits needed for register encoding.

The machine had < 32 instructions (really RISC)   so he used 5 bit instructions and some of them could be encoded into one instruction.

The last bit was special in that if it was set it triggered an automatic return after the instruction executed. Pretty clever I thought. 

 

There are so many interesting CPU architectures but now I find myself wondering:  What kind of CPU with the AIs will design for themselves? 

 

Forgot to mention the 10MHz version of this chip averaged 12MIPS with these encoded instructions.

 

[apersson850]

11 hours ago, TheBF said:

Was the 80 bit machine considered VLIW ? (very large instruction word) I had read about those in US military projects or some such thing 40 years ago.

No, the 80 bit wide instruction word is on the microprogramming level. Once such word is executed for each internal clock cycle. The user sees a narrower instruction, which when invoked executes a sequence of microprogram instructions (usually, some processors of RISC type executes everything in one cycle). In the particular case I don't remember how wide instruction words we had. Many CISC architectures have variable length instruction words. Like the TMS 9900 or the DEC VAX 11. Or, if you go the other way, the TI Programmable 59 calculator, which was different to the Hewlett-Packard 67. The TI 59 stored instructions in 1-6 bytes, the HP 67 always in one byte.

[speccery]

On 10/17/2023 at 12:27 AM, apersson850 said:

That special robotics controller I was involved in did have an instruction set adapted to the special needs of robotics. Coordinate conversions are common, so it did for example support sine and cosine for 32-bit floating point numbers directly in assembly language. It also had a register file where you could do something similar to BLWP, but the subroutine call shifted the 16 register workspace 12 positions in the register file. Thus if you called a subroutine in high level language (Pascal at that time) with no more than four parameters, they were stored in R12-R15 and when the call was done, they were in the new R0-R3. Results could easily be returned without having to push everything on a stack. Multiple efficient subroutines were possible, as long as you didn't run out of the register file. Returning from the subroutine shifted the registers back, so the results now appeared in R12-R15.

Thanks for sharing your experiences, very interesting read. What you explain about the special robotics controller sounds a lot like what SPARC CPUs do, they also have overlapping register windows. Unlike on the TMS9900, there is a massive register file, off-chip memory is not used register storage. The programmer sees 32 registers at a time, 8 of which are a global, and 24 are a window to a larger register file, which could for example have 160 registers in total.

 

@TheBFsome TI DSPs have VLIW architecture. I have programmed professionally some TI DSPs, but unfortunately it was before the VLIW chips like TMS320C6201 became available. The TMS320C6201 packs up to eight 32-bit instructions into one instruction packet, so the DSP fetches 256-bits worth of instructions every clock cycle. In practice it might be able to execute only some of those in a given cycle, as each instruction within a packet needs to use separate functional hardware units to run in parallel. The architecture places a lot of burden on the programmer or compiler to get the best speed out of the system. My understanding is that these DSPs are purely in-order execution engines and they have marker bits in the instruction stream to tell which instructions of a packet can be run simultaneously on a given cycle. For example you might have an instruction packet where three instructions can be executed in a cycle, and the remaining 5 would be merged with 3 instructions from the next packet, and then checked which of those can be run. But it all happens in order, even if there are no data dependencies. It is very interesting stuff. 

 

Contrary to that, from the Pentium Pro onwards the x86 architecture introduced speculative execution, register renaming and out of order execution. The CPUs became more or less data flow machines, requiring a lot of hardware to extract parallelism from non parallel instruction streams. Compared to that the VLIW designs are much simpler and more elegant - hardware wise...

[+TheBF]

6 hours ago, speccery said:

Thanks for sharing your experiences, very interesting read. What you explain about the special robotics controller sounds a lot like what SPARC CPUs do, they also have overlapping register windows. Unlike on the TMS9900, there is a massive register file, off-chip memory is not used register storage. The programmer sees 32 registers at a time, 8 of which are a global, and 24 are a window to a larger register file, which could for example have 160 registers in total.

 

@TheBFsome TI DSPs have VLIW architecture. I have programmed professionally some TI DSPs, but unfortunately it was before the VLIW chips like TMS320C6201 became available. The TMS320C6201 packs up to eight 32-bit instructions into one instruction packet, so the DSP fetches 256-bits worth of instructions every clock cycle. In practice it might be able to execute only some of those in a given cycle, as each instruction within a packet needs to use separate functional hardware units to run in parallel. The architecture places a lot of burden on the programmer or compiler to get the best speed out of the system. My understanding is that these DSPs are purely in-order execution engines and they have marker bits in the instruction stream to tell which instructions of a packet can be run simultaneously on a given cycle. For example you might have an instruction packet where three instructions can be executed in a cycle, and the remaining 5 would be merged with 3 instructions from the next packet, and then checked which of those can be run. But it all happens in order, even if there are no data dependencies. It is very interesting stuff. 

 

Contrary to that, from the Pentium Pro onwards the x86 architecture introduced speculative execution, register renaming and out of order execution. The CPUs became more or less data flow machines, requiring a lot of hardware to extract parallelism from non parallel instruction streams. Compared to that the VLIW designs are much simpler and more elegant - hardware wise...

Very neat stuff. Yes the out of order machines always "grated" against my real-time mentality for computing. (card carrying member of the old fart society) 

I didn't know about these TI DSPs with VLIW architecture. 

What you describe dove-tails with Chuck's machines in that each bit field managed separate hardware chunks (ALU, memory, stacks) as I understand it.

The approach was about removing the need for pipelining to maintain real-time predictability just as the DSP engines required and also to keep the gate count low.

And as you mentioned the compiler needed extra smarts to know what instructions could be stuffed together into one chunk.

 

[+OLD CS1]

All this discussion reminds me of my systems architecture class.  We were programming in MIPS.  We had a big pass/fail project: complete a set of tasks without stalling the pipeline, you passed; stall the pipeline once, you failed.  I loved that class.

[+TheBF]

28 minutes ago, OLD CS1 said:

All this discussion reminds me of my systems architecture class.  We were programming in MIPS.  We had a big pass/fail project: complete a set of tasks without stalling the pipeline, you passed; stall the pipeline once, you failed.  I loved that class.

Sounds brutal.  What instructions stall the pipeline typically? Branches?

[+OLD CS1]

17 minutes ago, TheBF said:

Sounds brutal.  What instructions stall the pipeline typically? Branches?

Been a long time, but going from memory, the CPU we worked with had a number pipelined operations, like address fetch, data fetch and store, certain maths, register operations, and so on.  Oh, I also remember we had a certain amount of cache to work with, so a certain amount of data fetching could be handled at the same time.

 

A poor example from memory, but as I recall we could fetch an instruction, load registers with data from sequential memory locations stored in the cache, load the next line of cache from memory, perform two register addition (math) operations, and check for a conditional branch all at the same time.  Stalling the pipeline would be attempting to load from two memory blocks at the same time, attempting more than a couple of register operations (move or shift, or math, &c) at the same time, and so on.  Again, not my daily immersion so I am certain someone else can come up with much better examples.

 

(Edit: Oh, and certain operations could flush or attempt to flush cache in the middle of using it, which would cause contention, too.  It was like a logical Tetris.)

 

It was indeed brutal, but so much fun.  It took me a few attempts to get the project right.

 

I actually just uncovered my class book while re-arranging my office.  I put it on my stack of stuff for me to re-familiarize.

[apersson850]

I think I have the data book for that robotics CPU somewhere at home. Now I've got a desire to locate it...

I know one of the first real applications for the robotics CPU was to control a robot playing table tennis.