ROM adventures (dev7rom)

[Phibrizzo]

Then, wouldn't it be simpler to add independent RTI instruction in newer version of ROMs?

BTW: why doesn't exist DEC instruction? (x--)

[lb3361]

Why no DEC instruction?

Having a DEC(b) instruction that runs as fast as INC(b) would take four precious bytes in page 3. Having a DECV(v) that runs as fast as INCV(v) would take two precious bytes in page 3. I have only four free bytes left in page 3 which I believe are best kept to organize a new page of opcodes in some distant future. Having instructions DEC(b) or DECV(b) using the prefix 0x35 would make them much slower and not very compelling when you can use SUBIV(1,v).

So the next question is what having INCV(v) at all? Turns out that this is used much more often than DECV would be.

In the LCC test suite:

Code: Select all

% grep INCV gigatron-lcc/gigatron/tst/*.sbk | wc -l
     142
% grep SUBIV gigatron-lcc/gigatron/tst/*.sbk | wc -l
      21
% grep ADDIV /gigatron-lcc/gigatron/tst/*.sbk | wc -l
      58

In the counts above, 19 out of 21 SUBIV instructions are SUBIV(1,...), but none of the ADDIV instructions are ADDIV(1,...) because the compiler would select INCV() instead.

[lb3361]

Latest changes:

• Added opcodes VSAVE and VRESTORE to save or restore a virtual interrupt context, and opcode EXCH to atomically exchange a byte. Together these instructions make it possible to implement preemptive multitasking. See viewtopic.php?t=463 and doc https://github.com/lb3361/gigatron-rom/ ... interrupts.
• Added opcode COPYS that copies data from a zero page address to the stack, or conversely, without changing vAC. This is documented at https://github.com/lb3361/gigatron-rom/ ... structions. Together with opcode ALLOC, opcode COPYS can be used to push/pop multiple values from the stack. This is particularly useful when a C function needs to preserve callee-saved registers in its prologue and to restore them in its epilogue, avoiding the need for a runtime subroutine.
• Added opcodes LOKEA/LEEKA that work for longs (4 bytes) like DOKEA/DEEKA for words (2 bytes) and PEEKA/POKEA for bytes. This is a minor optimization for programs dealing with long integers. For instance a single LOKEA(x) can replace the sequence DOKEA(x);ADDI(2);DOKEA(x+2). It takes three bytes instead of six and runs a little faster. Documented in https://github.com/lb3361/gigatron-rom/ ... arithmetic

[Phibrizzo]

Hello

I been watching latest doc of vCPU7 instructions and discovered that LEEKA and LOKEA have the same op codes #$3532.
What is correct?

[lb3361]

Hello

I been watching latest doc of vCPU7 instructions and discovered that LEEKA and LOKEA have the same op codes #$3532.
What is correct?

This was a documentation error. The opcode for LOKEA(XX) is 35 34 XX. The doc is now fixed.
I checked that the opcode was correct in Core/interface-dev.json, Utils/gt1dump.py, and gigatron-lcc/gigatron/mapsim/gtsim.c.
So this is just a documentation error with no additional consequences.

[lb3361]

Warning: incompatible changes in dev7rom

I just made a bunch of changes in dev7rom that makes it incompatible with earlier versions. Given that there are only a handful of people using it, I believe this is manageable. Just in case, both the https://github.com/lb3361/gigatron-rom and https://github.com/lb3361/gigatron-lcc repositories have a branch `dev7old` with the last version before the compatibility breaking changes.

What's up:

• Dev7rom always had ADDIV and SUBIV opcodes that respectively add or subtract a small constant 0..255 to or from a word variable. These are very useful for the C increment operators ++ and --. Alas they used to take 40 cycles in a single chunk that does not schedule too well. I replaced them by a single ADDSV opcode that adds a signed byte in range -128..127. This simplifies the carry management. So ADDSV runs in 30 cycles most of the time, but incurs an additional 26 cycles chunk when it crosses a half-page boundary and possibly a carry. Not only this is faster but it schedule better.
• Since this is already an incompatible change, I made a few more such as adding a DBNE instruction that is convenient when one program in assembly code (but almost useless to the compiler) and removing the LDNI instruction that loads a negative immediate because it was too rarely used to justify the space it took in the instruction page.
• Removing the ADDIV and SUBIV opcodes gave me plenty of space in the auxiliary instruction page (for the opcodes starting with prefix 35). I did not use much of this space except for two new opcodes FILL and BLIT. The opcodes FILL and BLIT see the gigatron memory as a 256x256 two-dimensional array. Depending on what's in the video table, the screen buffer is often a subarray of this 256x256 array. Both opcodes FILL and BLIT operates on subarrays with both rows and columns wrapping around.
• Opcode FILL fills a destination subarray defined by register vT2 (top left y in high byte, x in low byte) and vAC (h in high byte, w in low byte) with the value contained in the low byte of register vT3. It peaks at 60 bytes per scanline. For comparison the ROMv6 SYS_SetMemory peaks at 24 bytes/second and the version found in dev7rom peaks at 32. So this is really fast. You can try the following program on http://www.gigatron128k.com:
  

  TSTfill.gt1

  (1.25 KiB) Downloaded 123 times
• Opcode BLIT also targets the same destination array but, instead of filling it, copies the content of the equally sized source array whose top left corner is in register vT3 (y in high byte, x in low byte). It peaks at 16 bytes per scanline. For comparison, ROMv6 has SYS_CopyMemory that peaks at 12 bytes per scanline but only when all the planets are aligned. There is also code that automatically decides to progress forward or backward in order to ensure that we copy the destination pixels before overwriting the source pixels. To see this in action, try this version of Phibrizzo's zoom rotator viewtopic.php?p=4442#p4442.

The fact that FILL is four times faster than BLIT gives pause. Maybe sprites should be defined with some run-length encoding to reduce the need to read the source pixels. Conventional sprites in ROMvX0 are already as good as they'll ever get...

With this new rom comes a new version of the C compiler.

There is also an improved version of the emulation code on www.gigatron128k.com which features a single file loading dialog that can be used with tree kinds of files: .gt1 files for programs, .rom files for changing the running rom, and .vhd files for changing the contents of the virtual sd card mounted SPI0. I find nice to be able to change the rom at will. Note that for ROMv5a you need to unmount the spi card by loading a vhd file of size zero. Otherwise you trigger the ROMv5a buggy SPI card boot and are in for problems. The other roms work fine.

All this is in the GitHub as usual.

[Phibrizzo]

Why does the MOVIW instruction break the endians rule?

[lb3361]

Why does the MOVIW instruction break the endians rule?

I could not find a way to program MOVIW in 30 cycles (or less) otherwise.

Instruction DOKEI is the same, for the same reason.

BTW I just fixed an error in the vCPU7.md doc. Instruction DOKEI is 35 63, not 35 62.

[lb3361]

For the standard vCPU instruction set, see "vCPU instruction table" around line 482 of https://github.com/lb3361/gigatron-rom/ ... nguage.txt. For compatibility one needs to implement everything that is listed in https://github.com/lb3361/gigatron-rom/ ... rface.json.

For extra vCPU instructions, see https://github.com/lb3361/gigatron-rom/ ... s/vCPU7.md and https://github.com/lb3361/gigatron-rom/ ... e-dev.json for instance.

[Phibrizzo]

In the file vCPU7.md You wrote:

A third instruction EXCH is useful to atomically read-modify-write.

But now EXCH not exist. Do You removed it?
Now is EXBA instriction.