I didn't know...

[Willsy]

... that the TI Assembler had a bit shift. Never read that in the ED/AS manual.

 

As we all know, the assembler can resolve simple arithmetic at assembly time to calculate addressed, but I didn't know it could do bit shifts.

 

The symbol // is used for a bit shift, and it does a right shift, shifting in zeros on the left:

 

MSB     EQU >8000       ; switch on MSB
BIT14   EQU MSB//1      ; ooh! nice!
BIT13   EQU MSB//2      ; splendid!

[matthew180]

You never read it because I don't believe it is documented in the E/A manual, or anywhere else that I could find. Where did you see this? If anyone has a reference I'd like to see it. This makes me wonder if there are any other undocumented features... Does anyone have the source to TI's assembler?

[Willsy]

It's in Simplified 99/4 Assembly Language by Ken Culp.

[+acadiel]

Does anyone have all the op codes documented in order of op code?

[matthew180]

It's in Simplified 99/4 Assembly Language by Ken Culp.

 

But how did he know? I'd like to find an official reference. Even the 990 (mini computer) assembler docs don't mention any compiler operators other than + - * /

[+dhe]

Just happen to see this, as for my own edification I'm re-reading this book and checking it for errors.

 

"Currently, the author is an engineer with Texas Instruments where he has been writing system level software in Assembly Language for the 990 and 9900 computers for the last 7 years.
August 13, 1983"

 

Well positioned to know, I would say! ?

[matthew180]

Nice research!  Agreed, he would certainly be situated to know those kinds of internal details of the assembler.  However, these days we have tools like XDT99, and personally I'm not going back to using TI's assembler.

[+dhe]

There are a lot of insights that I've not seen else where.

Like - what purpose does NOP serve?

There are lots of ways to waste time (in assembler and life) - he says they mainly put nop s in assembler code when they wanted to use a debugger, it gave them ways to insert code in assembler with out re-compiling. Thanks makes perfect sense.

[matthew180]

Can someone post the ISBN or other information about the book?  11 years later I am suddenly curious, but I cannot find any reference that the book was published.

 

[+dhe]

As far as I know, it was never published and is only available on the Cyc. If you have a copy of the Cyc, it would be under /cadd/cyc/books/culp

[+InsaneMultitasker]

1 hour ago, dhe said:

There are a lot of insights that I've not seen else where.

Like - what purpose does NOP serve?

There are lots of ways to waste time (in assembler and life) - he says they mainly put nop s in assembler code when they wanted to use a debugger, it gave them ways to insert code in assembler with out re-compiling. Thanks makes perfect sense.

NOP (basically a jump to the next instruction) works well to replace code or render code useless such as calls to a subroutine or copy protection (think "sector editing"). 

 

NOP can also be helpful placeholder for self-modifying code and context switches.

[matthew180]

1 hour ago, dhe said:

As far as I know, it was never published and is only available on the Cyc. If you have a copy of the Cyc, it would be under /cadd/cyc/books/culp

Thanks for the reference, but what is "the Cyc"?

 

As for NOP, aside from what has been mentioned, it had more utility for talking to slow devices, or when it was common to count cycles to implement timing.  There are better ways, and more common to use hardware timers or interrupts for such things today.  Also, I don't even think a modern CPU would execute a NOP.

[+Ksarul]

The Cyc is the information disk that CADD ships with copies of their PC99 program. The Cyc by itself is well worth the entire purchase price of the program. . .

[+TheBF]

6 minutes ago, matthew180 said:

Also, I don't even think a modern CPU would execute a NOP.

The instruction ADDI x0, x0, 0 performs x0 <- x0 + 0, where 0 is an immediate encoded in the instruction. Such instruction has no effect on the state of RISCV and therefore is a NOP. Other alternative for a NOP on RISCV : ADDI x0, x1, 0.

assembly - RISC-V NOP instruction - Stack Overflow

 

I would never have guessed.

[+Lee Stewart]

10 hours ago, matthew180 said:

Thanks for the reference, but what is "the Cyc"?

 

In addition to what others have said, the “Cyc” part of “The Cyc” came from the word “cyclopedia” or “encyclopedia”.

 

...lee

[+mizapf]

12 hours ago, matthew180 said:

Also, I don't even think a modern CPU would execute a NOP.

There are still spinlocks in kernel code, and I can imagine that NOPs can be used there. Or do you mean that compilers don't produce NOPs?

[apersson850]

The way the TMS 9900 implements NOP is a way any CPU can do, since it's literally a jump to the next instruction.

[matthew180]

19 hours ago, TheBF said:

The instruction ADDI x0, x0, 0 performs x0 <- x0 + 0, where 0 is an immediate encoded in the instruction. Such instruction has no effect on the state of RISCV and therefore is a NOP. Other alternative for a NOP on RISCV : ADDI x0, x1, 0.

assembly - RISC-V NOP instruction - Stack Overflow

 

I would never have guessed.

 

Hmm, I would not have suspected either.  But a true RISC processor is not what I had in mind when I wrote my statement, since they forgo a lot of the CISC complexity in exchange for simpler faster instructions.

 

7 hours ago, mizapf said:

There are still spinlocks in kernel code, and I can imagine that NOPs can be used there. Or do you mean that compilers don't produce NOPs?

 

So let me be clear, I'm not claiming to know or stating a fact, just a speculation about NOP.  I also had modern x86 architecture CPUs in mind, which fetch multiple instructions to analyze, reorder, speculatively execute, and process via multiple execution units.  My instinct is that a NOP opcode (which is actually XCHG AX,AX on x86) will be determined by the CPU to have no affect and simply not execute the instruction, i.e. not dispatch it to any execution unit, and simply retire the instruction ("retire" is the term for an instruction that is complete).

 

I was not really referring to compilers, however I don't think they (modern gcc or clang) will generate a NOP.  It would also surprise me to learn that any modern kernel (*NIX, Windows, iOS) would be using NOP for locks, or anything else like that.

 

3 hours ago, apersson850 said:

The way the TMS 9900 implements NOP is a way any CPU can do, since it's literally a jump to the next instruction.

Using TI's assembler, NOP is a pseudo instruction (pg. 206 of E/A) which gets replaced with `JMP $+2`.  On the x86 the NOP is `XCHG AX,AX`, the Z80 actually has a real NOP instruction, and other CPUs will certainly do things their own way.  I don't think there is any typical method that CPUs implement NOP.

 

On the 9900, since JMP has an offset as part of the opcode and affects the PC (program counter), it involves an ALU cycle, and a full instruction cycle would be: Fetch, Decode, ALU->PC; Fetch...

 

However, the 9900 also has an unusual^1 characteristic that it will simply ignore any unrecognized opcodes, with a cycle like this: Fetch, Decode; Fetch...

 

Thus, any unused opcode on the 9900 could be used as a NOP, however that would not be save for forward binary compatibility with CPUs like the 99105 that added instructions that were previously unused; as well as some emulators (and the F18A GPU) that add instructions in the unused opcode space.

 

To detect an illegal opcode on the 9900 you have to use the IAQ (instruction acquisition) output from the CPU and an external lookup circuit.

 

1: I have not surveyed all CPUs to know if this is unusual, but it is for the ones I have looked into.

 

[apersson850]

7 hours ago, matthew180 said:

Using TI's assembler, NOP is a pseudo instruction (pg. 206 of E/A) which gets replaced with `JMP $+2`.

Yes, so it's really up to the assembler to define it. The CPU itself doesn't have any NOP. What you want is an instruction that doesn't do anything, doesn't affect any status bits and preferably consumes a minimal amount of program space. Thus jumping to the same place as you would execute the next instruction anyway is a good candidate. There are no other instructions that fulfill the same requirements, except for that any jump instruction would do. It doesn't matter if it's a conditional jump, since the destination for the jump is the same as you would end up at anyway. But the timing would be different. JMP is always 10 cycles. A conditional jump is only eight, if the condition is false.

RT is another example of a pseudo instruction in TI's aresenal. It's assembled the same as B *R11.

 

[+Vorticon]

On 7/13/2022 at 5:07 PM, matthew180 said:

Nice research!  Agreed, he would certainly be situated to know those kinds of internal details of the assembler.  However, these days we have tools like XDT99, and personally I'm not going back to using TI's assembler.

Whaaat? And miss all the fun?

I actually still use it quite a bit for interfacing projects where real hardware is needed. Coupled with a good 80 column editor like Stevie or Preditor and fast storage like a RAM disk or TIPI, it's really not bad.

Not sure I've had any use for bit shifting addresses in the assembler previously, but still an interesting feature. 

[Willsy]

The assembler commands are probably (speculating) a linked list. Might be relatively simple to view the assembler executable with a disk editor and follow the links to each command. I'm fairly sure it assembles a larger set of commands than the 9900 provides.

[matthew180]

8 hours ago, Vorticon said:

Whaaat? And miss all the fun?

I like *remembering* how fun it was, when that is all we had, and life was easy and computers were awesome.  Ahhh, the good old days.  These days, for me, real iron is fun for about 5 minutes when trying some games or testing software.

[+retroclouds]

20 hours ago, Vorticon said:

Whaaat? And miss all the fun?

I actually still use it quite a bit for interfacing projects where real hardware is needed. Coupled with a good 80 column editor like Stevie or Preditor and fast storage like a RAM disk or TIPI, it's really not bad.

Not sure I've had any use for bit shifting addresses in the assembler previously, but still an interesting feature. 

 

Also want to start using the assembler on my real TI-99/4a.

One of the next things on my list is integrating the assembler in Stevie. Will see how that goes.