Instructions are often "sprinkled" in a seemingly random fashion.
I have found a convenient convention/guidance :
- NOP is encoded with all-0s => easier to spot in a debug hex dump.
- INV (invalid) is with all-1s => this traps the core if it executes unprogrammed (E)EPROM.
It's totally arbitrary and INV is also found as all-0s to catch executing uninitialised RAM.
NOP is also often a special case for some instruction combination. But it's good to give the opcodes special values to ease decoding and extensions. NOP and INV can be pools of unused opcodes for later revisions.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
[this comment has been deleted]
https://github.com/kervinck/gigatron-rom/blob/master/interface.json
https://github.com/kervinck/gigatron-rom/blob/master/Docs/GCL-language.txt
Are you sure? yes | no
I should move these tables to the "data sheets" section on the website as well at some point I guess
Are you sure? yes | no
Gigatron's vCPU opcodes are jump offsets in the primary page that implements them. For slightly improved readability of hex dumps, I put RET on $FF.
Are you sure? yes | no
do you have an online listing of all the virtual opcodes (and their values) ?
I have seen a description of the physical opcodes at https://www.youtube.com/watch?v=QUfdASs82Lw
Are you sure? yes | no
Sure, the vCPU ISA definition is part of Docs/GCL-language.txt, and values/addresses/opcodes in interface.json of the GitHub repo: https://github.com/kervinck/gigatron-rom
Are you sure? yes | no
Hah! I was browsing at the same time :-D
Are you sure? yes | no