New vCPU instructions? (poll)

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
Post Reply

Which vCPU instruction to add?

Poll runs till 01 Oct 2019, 13:00

CMPW $DD
4
50%
HOP $DD
2
25%
LSRW or LSR
0
No votes
SW02 $DD
2
25%
Other (please comment)
0
No votes
 
Total votes: 8

User avatar
marcelk
Posts: 283
Joined: 13 May 2018, 08:26

New vCPU instructions? (poll)

Post by marcelk » 10 Jul 2019, 13:00

We can squeeze in at least two new vCPU instructions without breaking compatibility of existing GT1 files. We can do this by diverting INC and ALLOC, after entry, to another page and continue there. This makes them 6 cycles slower in total, but we can reuse the won space as the landing spot for new instructions. Not every instruction is suitable as a space donor this way, because their cycle count must not exceed 28.

Candidates for new instructions are (in alphabetical order):

CMPW $DD
Full range 16-bit comparison between vAC and the word at address $DD. With this C programs gain proper < > <= and >= without overflowing at 15-bits (issue #64)

HOP $DD
Branch into next page to offset $DD(+2). This makes longer functions possible, and C programs faster. It eliminates (some) hassle dealing with 256/96-byte segments in vCPU code.

LSRW or LSR
Shift word right 1 bit without going through a SYS function. It's unclear if we can do this in 28 cycles. Otherwise just LSR (byte)? Mind that we already have SYS functions for shifting words right by 1..8 bits. And multiplication and division routines work well without right-shifting (see for example TinyBASIC).

SW02 $DD
SWEET02: Switch to v6502 mode immediately. So inlining 6502 code without setting vLR first and going through a SYS function. After BRK (#0) continue in vCPU mode at page offset $DD(+2). In GCL notation it looks this this:

Code: Select all

...vCPUcode... [SW02 ....v6502code... #0] ...vCPUcode ...
Perhaps this can also be repurposed as a somewhat less efficient page hopping mechanism than HOP $DD, but I haven't thought it through very well. Something like:

Code: Select all

 ...vCPUcode... [SW02 #0
 *=$300
 ] ...vCPUcode...
Feedback is welcome, hence the poll.

Cwiiis
Posts: 26
Joined: 14 May 2018, 09:04

Re: New vCPU instructions? (poll)

Post by Cwiiis » 10 Jul 2019, 16:51

I've been a bit out of the gigatron loop, but trying to keep track via GitHub. I've voted for CMPW and HOP, and these seem by far to be the more useful of all these functions, especially considering what they alow for C programs. Of the limited amount of gigatron coding I've done, the biggest barriers have been dealing with small contiguous memory segments and copying large chunks of memory - anything that could help with either of those would be great in my opinion.

cmpxchg
Posts: 7
Joined: 07 Jun 2019, 11:44

Re: New vCPU instructions? (poll)

Post by cmpxchg » 13 Jul 2019, 18:24

I would like a bit more guidance to make an informed decision on what (two) items to vote in the poll :)
Knowing the expected instruction mix in existing vCPU programs and added value, speedups for example.

1.
The concept of a vCPU interface was known to me when I put my unit together, but I was unaware which instructions it *exactly* contained. Perhaps this could be in a manual form as well, instead of a tutorial. I did find an 'external' link, to github
https://raw.githubusercontent.com/kervi ... ummary.txt
and the more elaborate (but technically not defining a binary interface, but higher-level language interface)
https://raw.githubusercontent.com/kervi ... nguage.txt

Is this the complete document that defines 'vCPU binary compatibility' ?
- it is very terse, are all opcode/mnemonic arguments 16 bit or sometimes also 8 bit ?
- the width and signed/unsignedness of each register, and other state inside the vCPU
- method/library/call interface/ROM offsets for more complex functionality 'BIOS calls/software interrupts', framebuffer, character set
- layout for conditions, link register, leaf call concepts, other new internal state description

perhaps better formatting in a table and releasing it as a PDF like other CPU instructionsets makes it easier to understand. At first glance it seems hardly more functional than the native hardware CPU instructionset, except 16 bit :) - but still having the same-ROM page limitations everywhere.

2.
Then, the vCPU binary compatibility is technically not needed - the hardware is executing the 128 kbyte ROM code - but since it is currently not user-programmable (no ROM emulators in wide usage), I understand your wish of defining a new variant to having 'binary compatibility' for vCPU programs loaded and interpreted in the 32 kbyte RAM, using the vCPU in ROM. Perhaps also to maintain pluggyMcPlugface compatibility.

3.
Are there any suggestions for suitable off-the-shelf EPROM emulators for users that want to run their own ROMs and experiment at that level ?

One could also think of to NOT standardise the vCPU interface, but instead provide a higher-level abstraction, like the BASIC syntax and ways to make 'hooks' (dummy calls to intercept program flow) to add new tokenized basic instructions in... a variant of vCPU language matching the ROM inserted in the unit. DISK ROM basic did use that back in the old micro days, having a set of hooks as an interface.

User avatar
marcelk
Posts: 283
Joined: 13 May 2018, 08:26

Re: New vCPU instructions? (poll)

Post by marcelk » 13 Jul 2019, 21:27

cmpxchg wrote:
13 Jul 2019, 18:24
I would like a bit more guidance to make an informed decision on what (two) items to vote in the poll :)
There's no hurry. The poll is open until the end of September :lol:
Knowing the expected instruction mix in existing vCPU programs and added value, speedups for example.
De concept proposals above are as concrete as I can make them without actually implementing, testing and characterising.
Is this the complete document that defines 'vCPU binary compatibility' ?
It looks like you found links to (some of) the documents in the Docs/ directory of the ROM repository. That's where we intend to maintain all ROM documentation.
- are all opcode/mnemonic arguments 16 bit or sometimes also 8 bit ?

Code: Select all

The vCPU interpreter has 34 core instructions. [..]
Most instructions take a single byte operand, but some have two and others none.

The formulas are pseudo-formal. Better take them with a grain of salt.

Mnem. Encoding  #C Description
----- --------- -- -----------
ST    $5E DD    16 Store byte in zero page ([D]=vAC&256)
STW   $2B DD    20 Store word in zero page ([D],[D+1]=vAC&255,vAC>>8)
LD    $1A DD    18 Load byte from zero page (vAC=[D])
LDI   $59 DD    16 Load immediate small positive constant (vAC=D)
LDWI  $11 LL HH 20 Load immediate word constant (vAC=$HHLL)
So 'DD' or 'D' are intended to represent a single byte. 'LL HH' is intended to represent a 16-bit word in little-endian order. '[X]' is intended to represent a RAM location, as in the native instruction set. 'vAC=D' is intended to mean that the (16-bits) vAC gets the (unsigned) 8-bit value D, and therefore clearing its high 8 bits in the process.
- the width and signed/unsignedness of each register,
From the same link:

Code: Select all

The virtual regisers are 16-bits (except vSP) and reside in the zero page.

vAC  is the virtual accumulator [...]
vPC  is the virtual program counter [...]
vLR  is the link register [...]
vSP  is the stack pointer. The stack lives in the zero page top and grows down.
So vAC, vPC and vLR are 16-bits, and vSP is 8-bits.

Registers don't have a signedness by themselves. They're just untyped bits as in any other processor. Some instructions must interpret them in a certain way however. The only ones where this matters for us are BGT, BLT, BGE, BLE: they treat vAC's contents as signed as they compare vAC to zero (>0, <0, ≥0, ≤0). ADDxxx and SUBxxx instructions don't care about the sign because of the two-complement interpretation by these four.
and other state inside the vCPU
From the README.md file in the top level of the repository (the one that GitHub displays) we have these:

Code: Select all

[Note: In the next section, names in parentheses refer to *internal*
variables that are subject to change between ROM versions. See for a
more detailed explanation on compatibility the file Docs/GT1-files.txt]

Address   Name          Description
--------  ------------- -----------
0015      (vTicks)      Remaining interpreter ticks (=units of 2 CPU cycles)
0016-0017 vPC           Interpreter program counter, points into RAM
0018-0019 vAC           Interpreter accumulator, 16-bits
001a-001b vLR           Return address, for returning after CALL
001c      vSP           Stack pointer
001d      (vTmp)        Scratch storage location for vCPU
001e      (vReturn)     Return address (L) from vCPU into the loop (H is fixed)
So there are more variables holding vCPU state, but they tend to change between ROM versions.
- method/library/call interface/ROM offsets for more complex functionality 'BIOS calls/software interrupts', framebuffer, character set
That's what SYS extensions do. Docs/SYS-functions.txt attempts to document how the mechanism works. It's a summary of several explanations given here in the forum and from comments in the source code.

There are numerous example programs in Apps/ that people use to figure out how to do specific things with them. The simpler ones (Blinky, HelloWorld) and the more recent ones (TinyBASIC) are much better commented than the older ones (Racer).

The online BASIC tutorial goes pretty far in explaining the video and sound system.
At first glance it seems hardly more functional than the native hardware CPU instructionset, except 16 bit :) - but still having the same-ROM page limitations everywhere.
From the first paragraph of the document you linked to:

Code: Select all

vCPU's advantages over native 8-bit Gigatron code are:
 1. you don't need to think about video timing with everything you do
 2. operations are 16-bits, and
 3. programs can run from RAM.
  1. Is the reason we have applications at all: even Snake wouldn't exist without vCPU. The cycle counting to properly generate horizontal sync pulses every 200 cycles is tedious for regular application level code. In theory it can also be handled by a compiler, but nobody has walked that path yet.
  2. Is not really essential, although it makes it easier to build typical applications quickly. It's also a bit more efficient than handling just 8-bits worth of data per instruction (more "bang per buck").
  3. Is the reason you can load programs into the Gigatron with Loader and without changing the EPROM.
perhaps better formatting in a table and releasing it as a PDF like other CPU instructionsets makes it easier to understand.
I believe everything is documented and every question gets a decent answer (that often results in documentation updates as well). That has led to quite a few programs, emulators, and even a C compiler. Reconciling, in a PDF version, what we have written down already is an excellent suggestion for a next phase. Thank you!
2.
Then, the vCPU binary compatibility is technically not needed - the hardware is executing the 128 kbyte ROM code - but since it is currently not user-programmable (no ROM emulators in wide usage), I understand your wish of defining a new variant to having 'binary compatibility' for vCPU programs loaded and interpreted in the 32 kbyte RAM, using the vCPU in ROM. Perhaps also to maintain pluggyMcPlugface compatibility.
We don't want to render existing programs worthless by making arbitrary incompatibility changes. People put a lot of effort into making those programs. When they share them in Contrib/ as .gt1 files, we even make an effort to test them as well.
3.
Are there any suggestions for suitable off-the-shelf EPROM emulators for users that want to run their own ROMs and experiment at that level ?
Perhaps that's best discussed in a different thread. The FAQ has some ideas.

Post Reply