TMS99000 stack related instructions

[+retroclouds]

It was mentioned that the TMS99000 family of processors (e.g. TMS99105) have stack related instructions (or is it an addressing mode?).

I checked the data manual, but I must be overlooking something. I can’t find anything related 

 

http://bitsavers.informatik.uni-stuttgart.de/components/ti/TMS9900/TMS99105A_and_TMS99110A_16-Bit_Microprocessors_Preliminary_Data_Manual_Nov82.pdf

 

Do we have any example where stack manipulation is done on the TMS99000 family of processors?

[Stuart]

Two stack-related instruction:

 

-- BLSK - branch immediate and push link to stack. Uses a workspace register as a stack pointer, and the stack grows down in memory.

 

-- BIND - "The BIND instruction serves as the inverse of a BLSK instruction if the register indirect autoincrement addressing mode is used. Indexed addressing used with BIND implements a powerful CASE or multi-way branch instruction where the immediate operand points to a table of branch addresses and the register contents selects which way to branch."

Edited September 19, 2021 by Stuart

[+TheBF]

6 hours ago, retroclouds said:

It was mentioned that the TMS99000 family of processors (e.g. TMS99105) have stack related instructions (or is it an addressing mode?).

I checked the data manual, but I must be overlooking something. I can’t find anything related 

 

http://bitsavers.informatik.uni-stuttgart.de/components/ti/TMS9900/TMS99105A_and_TMS99110A_16-Bit_Microprocessors_Preliminary_Data_Manual_Nov82.pdf

 

Do we have any example where stack manipulation is done on the TMS99000 family of processors?

 

"Hmmm strong the Forth in this one is" 

 

[+retroclouds]

I knew this was the right place to ask ?

 

Reason I asked about the TMS99000 stack related instructions, is because I have some assembly programs I've written that would work really well with those.

Also, it's interesting to see how the processor family evolved. 

 

Edited September 22, 2021 by retroclouds
Spelling fixed

[+TheBF]

On 9/19/2021 at 10:01 AM, retroclouds said:

I knew this was the right place to ask ?

 

Reason I asked about the TMS99000 stack related instructions, is because I have some assembly programs I've written that would work really well with those.

Also, it's interesting to see on how the processor family involved. 

 

Just curious. Are you using a stack in those programs now?

 

I find the old 9900 not too bad at dealing with them even though they were not baked into the hardware.

Having a stack gives you options for those times when all you need is a bit of space rather than setting up a new workspace and vector. 

 

 

[+retroclouds]

2 hours ago, TheBF said:

Just curious. Are you using a stack in those programs now?

 

I find the old 9900 not too bad at dealing with them even though they were not baked into the hardware.

Having a stack gives you options for those times when all you need is a bit of space rather than setting up a new workspace and vector. 

 

 

yes, my spectra2 library only uses a stack.

It was originally implemented for doing arcade games with scratchpad memory only. It was at the core of the ROM version of Pitfall. Since then I kept the habit of using a stack, also in my Stevie editor (also has spectra2 at its core).

 

That’s why I think it would be a good match for the TMS99105.

 

Having said that, would like to change my design for using multiple stacks.

A return stack and a value stack. As it is now, they are combined in a single stack. 

Think that the advantage of having an additional return stack is that it would be more stable if you mess up, and it’s easier to keep track of your call chain. Well at least that’s what I noticed with my trampoline function (that one has a separate stack for keeping track of jumps between banks). Have been holding back on that redesign, because I have thousands of lines of code to deal with and it’s already stable as it stands now.

Edited September 22, 2021 by retroclouds

[+TheBF]

11 hours ago, retroclouds said:

yes, my spectra2 library only uses a stack.

It was originally implemented for doing arcade games with scratchpad memory only. It was at the core of the ROM version of Pitfall. Since then I kept the habit of using a stack, also in my Stevie editor (also has spectra2 at its core).

 

That’s why I think it would be a good match for the TMS99105.

 

Having said that, would like to change my design for using multiple stacks.

A return stack and a value stack. As it is now, they are combined in a single stack. 

Think that the advantage of having an additional return stack is that it would be more stable if you mess up, and it’s easier to keep track of your call chain. Well at least that’s what I noticed with my trampoline function (that one has a separate stack for keeping track of jumps between banks). Have been holding back on that redesign, because I have thousands of lines of code to deal with and it’s already stable as it stands now.

Thanks. That's Interesting that you want to make two stacks. 

Chuck Moore came to the same conclusion in the late 60's with his early Forth systems. It has merit if you have the registers to support a stack for each purpose IMHO.

Since then, like your trampoline stack, people have added Floating point stacks, control-flow stacks and others in Forth systems.

They sure are a handy data structure. 

 

Although Chuck's CPUs all have two stacks I don't know of another machines that supports more than one stack in hardware...

Just checked and apparently Itanium has/had two stacks and ARM is kind of agnostic in that it can use any registers as stack pointers since POP/PUSH are just aliases for load/store instructions.