The 6502 only has 56 opcodes.
The db also includes modern variants of the 6502.
The 6502 instruction set as a database
11–20 of 31 posts
Re: The 6502 instruction set as a database
#12Earlier quoted context omitted.
The ability to ship SQL views that join multiple tables as part of the schema is pretty cool, and something you can't come close to replicating with CSVs. https://lite.datasette.io/?sql=https://gist.github.com/simon...
I like how it looks, and I appreciate the effort that went into it, but other than using it to export a table in just a right format that you will then embed into your assembler directly, I'm not sure how to use it. And I use opcode references [1] very often (sometimes daily, depending on the project). I even wrote my own disassemblers. But I mostly use opcode references for manual cross checking, so maybe I'm not a…
The ability to export data from a table or query in whatever format you need is one of my favorite things about distributing data using SQLite.
Re: The 6502 instruction set as a database
#13Inspiring. I would love for the author's plan (pasted below) to get applied widely across key information sources:
Instead, I hatched a plan:
1. Collect sources, and encoded the raw data in a machine-readable form
2. Study those sources, and encode my understanding as assertions,
sanity-checks and validations of that data
3. Synthesise that data according to my understanding, and verify it
against the sources availableRe: The 6502 instruction set as a database
#14From the comments, it even seems to account for some instructions needing an extra cycle when crossing page boundaries, nice! This seems pretty comprehensive then.
Re: The 6502 instruction set as a database
#15Great idea, this could be valuable for people who write their own assembler. It's the first time I see an instruction set as a relational database, which I would imagine is a very portable way to describe a machine, perhaps it might be worth collecting other machine specs in that same format and then create a portable assembler that uses the specficic DBs.
Table-driven assemblers (and disassemblers) have been a thing for a long time, especially for more obscure/embedded architectures. Reverse-engineering/analysis tools likewise have traditionally done the same, but with additional semantic information for each instruction. A quick search for table-driven compilers reveals some mid-century papers.
Re: The 6502 instruction set as a database
#16Likely useful: https://github.com/mist64/perfect6502 and http://www.visual6502.org/. These are transistor-level simulations based on die shots. From these you can derive the cycle times of each instruction with 100% confidence.
Re: The 6502 instruction set as a database
#17Great idea, this could be valuable for people who write their own assembler. It's the first time I see an instruction set as a relational database, which I would imagine is a very portable way to describe a machine, perhaps it might be worth collecting other machine specs in that same format and then create a portable assembler that uses the specficic DBs.
Ghidra uses SLEIGH for this purpose https://fossies.org/linux/ghidra/GhidraDocs/languages/html/s...
> A Language for Rapid Processor Specification
From a SLEIGH description, the assembler, disassembler, and even decompiler can be synthesized.
It's a DSL not a database schema, but fundamentally it's the same idea.
Here's their definition of the 6502: https://github.com/NationalSecurityAgency/ghidra/blob/cae919...
Re: The 6502 instruction set as a database
#18The 6502 only has 56 opcodes. The db also includes modern variants of the 6502.
> The 6502 only has 56 opcodes
In terms of bytes that the original CPU officially recognised as instructions, it was more like ~150 (working from old memories, I may be off by one or few there). Some of the other ~106 did something unofficially, and a number were valid instructions on later versions of the design.
That ~150 were grouped into 56 instructions, many with multiple addressing modes (so "load A immediate", "load A direct", "load A indexed", etc, were different opcodes but considered the same instruction).
Because register use was far from orthogonal (one accumulator, two index registers, and a flags register), instructions for them were considered different (LDA, LDX, & LDY, for load for instance) where in other instruction sets (for chips with multiple general purpose registers) they might be considered the same instruction affecting a different register, though considering them the same instruction didn't reduce the opcode count just the instruction group count.
(Apologies for failing to keep my inner pendant properly inner!)
Re: The 6502 instruction set as a database
#19Something I realized years ago, the 6502 instruction set is small enough that it can be (almost) entirely implemented as memory look up — no actual logic computation need occur.
Re: The 6502 instruction set as a database
#20The 6502 only has 56 opcodes. The db also includes modern variants of the 6502.
> The 6502 only has 56 opcodes In terms of bytes that the original CPU officially recognised as instructions, it was more like ~150 (working from old memories, I may be off by one or few there). Some of the other ~106 did something unofficially, and a number were valid instructions on later versions of the design. That ~150 were grouped into 56 instructions, many with multiple addressing modes (so "load A immediate",…
The original 6502 had exactly 151 opcodes, the same as the number of pokémon in the original Pokémon games.