RISC

/prog/, I'm working on a RISC instruction set that is more RISC than any RISC out there. I've devised an instruction format, plus fifteen core instructions that should suffice for any programming out there. The instruction format, instruction forms, and instructions can be found here:

http://jsbin.com/ekuwap

Any comments or suggestions?

>>80
>>79

>>76
That reminds me of this:

4.1.1 REGISTER/IMMEDIATE OPERAND FIELD

000 8-bit immediate value follows instruction (#xx)
001 16-bit immediate value follows instruction (#xxxx)
010 32-bit immediate value follows instruction (#xxxxxxxx)
1nn memory operand pointed to by D0 through D4 (@D0-@D4)

4.1.2 FLEXIBLE OPERAND FIELD

000nn memory operand pointed to by D0 through D4 (@D0-@D4)
001nn 32-bit registers D0[W1:W0] through D4[W7:W6] (D0-D4)
01nnn 16-bit registers W0[B1:B0] through W7[B15:B14] (W0-W7)
1nnnn 8-bit registers B0 through B15 (B0-B15)

from >>77

Plenty of room!
make sl and sr Opcode 101 and 110 respectively, and you can use
opcode#2 as the log-step variable

can do a Rot 127 (if possible) in 7 instructions using just one... and in 3 instructions using both? shiftRight:64 + shiftRight:64 + shiftLeft:1...

>>78
If you access memory that doesn't exist you would just read the value from a floating databus (FFs if there's termination/pullups, other values are possible but it doesn't matter here) and try to write it to the same nonexistent location, so nothing actually happened.
This is usually but isn't always true because of memory-mapped I/O. Sometimes reading from a memory location and writing a value back (even the same value) has side-effects. Especially since that's probably how this CPU will do I/O since there are no IN/OUT port instructions. I know that on the SNES there are some memory-mapped I/O ports that are "open bus" on read but valid on write or that have destructive reads. An m instruction with the same register on those is definitely not a NOP!

>>83
If this CPU didn't have multiple-bit shifts, this would be a good idea (the IBM 5110 can do any 8-bit rotate in 3 instructions by doing this), but it can already shift by any number of bits in one instruction, so a hardware implementation would use a barrel shifter. In that case rotate can use the same format as shifts and then it could rotate by any number of bits in one instruction. It wouldn't make sense to use multiple rotate instructions in an architecture that already needs a barrel shifter and can already do them in one cycle.

>>84
When I wrote "memory that doesn't exist" I was referring to the truly nonexistent parts of the memory address space, which have no hardware on the bus to respond to.

>>85
To be complete, the whole family of shift/rotates is
* left shift 0-pad
* right shift 0-pad
* left shift 1-pad (not as useful but included for completeness)
* right shift 1-pad (aka "arithmetic"/sign-preserving shift)
* left rotate
* right rotate
* left rotate through carry
* right rotate through carry
...which is conveniently encoded in 3 bits.

That also raises another point: Your CPU is missing multiple-precision arithmetic (ADC/SBC) instructions.

>>86
I only quoted part of your post. You also counted m instructions using the same source and destination registers as NOPs (by assuming it's either RAM or nothing). If the register points to an I/O address, it isn't a NOP. That sort of thing is why C has the volatile keyword.

>>82
could use something like this if you ran out of op-codes

i think most of the instructions so far would fit in just five bits of opcode, bar that 'i, so what op/? could do is use the very first bit as a 16-bit / 24-bit length instruction signal?

...full new 23 bit space to use//larger address spaces + more opcodes?

>>88

variable length instructions
vomitchan.svg

What about operations on the instruction stack..?

>>89
fixed length instructions
bloatedvomitchan.xml

Most of the book is free. I suggest you read it:
http://www1.idc.ac.il/tecs/

Signal_code a=0 [Plus eight bit?]
|a|/Opcode a
...|aa|/Opcode b
......./[bbb]/

Could Easily keep expanding like this..?

Signal_code a=1
|a|/Signal_code b=0 [Plus another 8 bit?]
...|b|/Opcode c?
....../[cc]// Opcode D?
.........../[dddd] (one byte of signals//two bytes to spare..?)

mnemonic pushPageVal |1|0|00|0001| source Reg[5 bit] | dest L1[8 bit] ?

mnemonic popPageVal |1|0|00|0001| dest L1[8 bit] | source Reg[5 bit]

>>93
Fuck off, n3n7i.

...might i ask where is the instruction stack?

...it's a single instruction stack? (It only holds the current instruction..?)

Reg Address compressed instructions?
eg using some signal/marker to specify re-using the last used register? / L1 / etc?  [special cased repeats? reuse entire last instruct?] /&/ SIMD-like instructions (single op-code with many source/dest's)?

...Also, there are no base-level [array / memory in general]-specific instructions..?

stack push / pop..?

...mnemonic i could be a push (stack size is unknown // first in last out access order?) and takes 8 * >>1 left rot's to return a val? // can only push 8-bits at once/ and pop one bit per instruct?

Barrel rotate (?) means speed is probably not an issue..? But you still use 16 bytes of code for a rotate?

*16 bytes of code for a pop
cisc-esque but..

...special pre-emptive source/destination range instructions?

the idea being to cut out a bunch of fairly plain source/dest fields in the usual instructs, instead using a bit larger preempt code followed by x micro 8bit-all-opcode(?) instructions..

>>92
There's this too:
http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319

>>93
You could do that, but your instruction decoder would get too complicated and it'd be slow as fuck.

>>100
probably, though perhaps not?

you only have to check the very first bit to see if its a 16bit instruction >> branch to 16bit decoder //etc. etc.

just using a big select case would be pretty slow// there would be binary-tree style decoders already?

>>100
Not really. That's hardly "complicated", and multibyte instructions/multiple single-byte ones could be easily decoded in a single clock if the databus is wide enough.

Look at how the x86 decoder works. It can determine the instruction length in 1 cycle, and do it for multiple instructions at once. i7s are not "slow as fuck" either.

>>101
You're not writing software here.

>>102
If you can determine the total number of instruction bytes from the first byte then sure. This was one of the limiting factors of the VAX. Intel also spends a lot of resources hand-optimizing transistors. It's not really babby's first CPU material.

>>102,103

you could also build, then use, a single instruction to specify the length of the next n instructions? /depending on how much they vary might be as little as one bit per instrct.

can always compress the most common/smallest? length(s) with "shannon's entropy"(?) i think its called, right down to one bit regardless of the number of items, as long as you don't mind a bit of expansion..

1, 01, 001, ... // 01, 10, 001, 110, ... <<this

reminds me of an old run-code compression i tried to invent after reading once =) never got that to work..

...think i was doing it backwards?

2 bit -> 1 / 01 / 001 / 000 (typically expands... But because it is complete in both directions, can be used in either direction eg [2 bit] <---> [1 / 01 / 001 / 000]

for comparison a block of data can be broken up into 2 bit pieces and represented as [1 / 01 / 001 or 0001] but not the other way round..

same for [01 / 10 / 001 / 110 / 000 / 111] -> 3 bit but  3bit -/-> [01 / 10 / 001 / 110 / 000 / 111]

a good three bit
[3bits] <--> 01 / 10 / 001 / 110 / 0001 / 1110 / 0000 / 1111

...append a compression type marker and recompress?
especially if you have a few different versions..?

>>102
i7 still uses RISC representations internally, right?
To counter a earlier argument you made, the RISC philosophy is still very applicable when it comes to doing more per clock cycle.
Fancy superscalar tricks like out-of-order execution require very efficient decoding, and IIRC Intel's processor does all of that after the conversion stage.

>>93
>>105
You just went full iAPX432, nigga. Never go full iAPX432.

>>109
will google

>>109
One of the very few processors with variable-bit-length instructions AND forced OOP at the hardware level.

Intel was too ambitious and failed with that one.

>>108
Micro-ops, which are even simpler representations than RISC instructions. The "RISC philosophy" you're referring to is different from what I was referring to; the latter would be the single-cycle-instruction pipelined CPU model that they still teach in CS classes (unfortunately), often along with now-outdated points like "we can increase clock speed if we make instructions simpler". Superscalar and OOE requires multiple decodes per clock too, which is facilitated by short/variable-length instructions. [Assuming a 32-bit databus, a fixed-length 32-bit instruction RISC would be able to decode one instruction per fetch, while e.g. x86 could decode 4 1-byte instructions --- and execute them in parallel if they're things like 4 independent register increments.]

>>105
Give these a read:
http://dl.acm.org/ft_gateway.cfm?id=1835424&ftid=62047&dwn=1&CFID=44651829&CFTOKEN=30301632
http://www.iro.umontreal.ca/~latendre/publications/techReport1219.pdf