<oriansj>siraben: well the problem with brainfuck and other interpreted languages being used early in bootstrapping is they make the easier bits easier but make the hard bits harder. <oriansj>for example in M0 the easy bit is figuring out the #DEFINEs you want to use and an interpreter will allow you to skip that step. The hard bit is making sure your logic is correct; an interpreted language actually makes that much harder to ensure it is done correctly. <oriansj>that being said if one was willing to be wasteful of bits; I'm sure there is a minimal ISA that could be done in a few hundred instructions. <oriansj>say a version of sweet16 with an 8bit opcode and a few additional instructions for handling bytes and 32bit values <oriansj>muurkha: the biggest part of any instruction set interpreter is the decode logic <oriansj>you see it even in knight: 47298 vm_decode.c vs 46191 vm_instructions.c and that is with an extremely simple decode format for instructions that knight has <muurkha>knight is a pretty complicated instruction set <muurkha>in my implementation of Chifir the instruction decode and implementation of the instruction set is 20 lines of C <muurkha>the other 50 lines include reading in the image, reading the keyboard, etc. <muurkha>at some point later I wrote a screen output thing for it which was another 30 lines ***Guest2562 is now known as roptat
<oriansj>muurkha: very true; knight has a bunch of instructions which exist to make certain things simpler; a handful of which I never implemented because they were not needed (the pack and unpack instructions for example) <oriansj>also having just 16 instructions does make certain problems messier. for example having to do jump 4, the immediate, sub pc, 4 -> r0, load [r0] -> r0 to load a 32bit value, rather than just load immediate -> r0 <oriansj>or having to do masking instructrions because you don't support byte/half read/writes <oriansj>now one certainly could have a complex enough instruction set in 8bits of opcode to be simple and easy to program in. while being tiny enough to be possible to implement in hex0. It is just a sort of exercise in hack value that hasn't been done yet. <muurkha>Chifir avoids load immediate by virtue of not having architectural registers except the PC; all instructions are memory to memory <muurkha>and its memory is 32 bits wide, so while you could pack multiple bytes into a word if you wanted to, usually an easier alternative is to not do that <muurkha>Wirth RISC does have load immediate and both byte and word loads and stores <muurkha>depending on how you count, it has between 21 and 42 instructions <muurkha>because it's designed for RISC implemenation its instructions are 32-bit words, though, not 8-bit bytes <bauen1>rv32i has around 38-40, maybe i miscounted a bit, including load / store byte, word <muurkha>yeah, and it's probably more comfortable to program in, but it omits floating point and carry flags <muurkha>you could unshuffle the rv32 opcode encoding if you were just trying to make a machine that was easy to program <muurkha>all the bitfields are multiples of 4 bits <bauen1>muurkha: all things considered, i'd rather take the benefit of making it easy to implement in hardware / fpga, as you'll only be touching raw instructions for the first few programs, after that you'll go with macros of some sort <bauen1>muurkha: oh yes, that does look nice indeed <muurkha>dunno, I've spent a lot of late nights puzzling over i386 opcodes (often perversely encoded in hex instead of octal) <fossy>oriansj: stikonas we can just point to the commit if required, we've already had to cd into different dirs etc. it's just a bit annoying westes doesn't understand, but its still workable