ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@cdimauro

Quote:

cdimauro wrote: @Karlos Quote: Karlos wrote: @cdimauro The FPU instructions that I've introduced are part of what I actually want for a minimal scalar implementation so while I appreciate they aren't necessarily used often, there are reasons I chose those. I haven't said to don't implement them. Rather to move them from the regular opcode space (16-bit) to the extended one, to free some precious opcodes. You can still execute them, so there's no problem from this PoV.

Noted, of course. If I find I need further core opcodes, these will be the first to be "revised back" to where they came from.

Quote:

Quote: Obviously this only makes sense where there are no other stack parameters. Exactly. So, not worth an instruction only for that: not a common use case.

It's not an extra instruction though, it's just making use of otherwise unused operand space. Seems like an easy feature to add for almost no additional cost.

Quote:

Quote: I take the point regarding dbnz. I figured a 64 bit counter may be overkill tbh, but it it turns out that on 64 bit JIT implementation (which I probably will want to have a go at eventually), then maybe affecting all register bits makes for a more efficient conversation. It's also for not repeating the mistake that Motorola did with the 68000, where DBcc instructions have only a 16-bit counter. Just use the same size of the register and you're "future proof".

I think using a signed full register width makes sense when the comparisons with the value are in fact always going to be around zero in this case. Realistically it's going to come down to "branch if not zero" and "branch if not negative", since we are decrementing. Technically, I suppose you could have "branch if negative" that would catch the sign wrap around. I wouldn't want to wait that one out

Quote:

Quote: The branch size of it was "because I could". In principle it could be used to implement other conditionals since the counter will be a signed value. TBC. Indeed. I haven't reported it because I didn't want to overload the review with too many things, but the idea is the same (with the usual main goal to free 16-bit opcodes) because usually conditional branches are short in range, so the 4-bit field could be use to pack together many conditions.

As above, I actually don't think there are so many useful conditions to use here. The point about the shorter branch is a good enough case, really. You will note that all other compare-and-branch and the case instruction all use 16-bit offsets, so I'm happy to to drop the 20-bit offset here and reserve the bits for something else. One thing might be to permute the instruction, itself. For example, you could use the 4-bit value to encode a decrement step in a range 1-16 if all you want is just DBNZ. Or you could use it to implement varying integer sizes, e.g. dbnz.i8 and such. I don't want to add too much conditional logic to the implementation of the operation of course.

Quote:

BTW, on your ISA you miss a 8-bit conditional jump instructions, but due to the missing condition codes register this is practically impossible to implement because of the lack of space.

BEQ_8, BGR_I8, BGREQ_I8 are all enumerated and BNZ supports 8 bit too. Do you mean short branch displacement versions?

Quote:

Quote: On a general note, I don't want to use any fields smaller than 4 bit and I want to have them in predictable places. For example, the main interpreter loop will always decode the operand byte as two nybbles up front because except in a couple of cases, they are always going to be used as such. This keeps the interpreter loop code more compact as it's a significant bit (no pun intended) of subexpression elimination. Designing the opcode for efficient software interpretation is a factor here. Absolutely. This was exactly the same thing which I did with WPython: the 16-bit opcode is always split as two 8-bit parts, which I always decode (and then immediately "jump" switch/case depending on the first one, which is the opcode, and which is always decoded first to make it ready while the processor is decoding the operand). So execution loop is very small, and always the same, and decoded instructions immediately find the operand (if they needed it).

+1

Going back to some other points you raise:
Quote:

INV_x - For floating point operands, the reciprocal of the value stored in S is calculated and stored in D * Better to rename it in something like RECP or RECPR, since it's a completely different operation compared to the integer one.

This is fine. I used "inverse" in the arithmetic sense when talking about real numeric operands. I'm happy to rename that.

Quote:

LD_II, ST_II - offset by the 32-bit signed index value in I * Should be 32-bit for 32-bit ISA and 64-bit for 64-bit ISA. - Scale value is applied as a shift, meaning the largest scale factor possible is 32768. * A so big scale value is rarely used. 1x to 8x makes more sense. And you can use the two free bits to define a small offset (which is always useful)

I'll consider this but I want to avoid multiplication for the sake of simplicity on low end targets, e.g. 68K. I agree the larger offsets won't be used much, but I have implemented stuff that breaks down 2D maps and such into 4KiB data chunks. A big shift is handy for that sort of thing.

Quote:

MV_x - The value in S is copied to the D. Where the operation size is less than the register size, the upper bits of the register are not affected. * Just define a single MOV instruction for integer registers and another one for floating point registers: moving small portions of registers aren't so frequent instruction to justify a specific opcode. If you think that it's really important, you can define an extended opcode for it.

It's probably the 68K coder in me that wants to keep this. If I discover a set of new opcodes I definitely want to bring into the core set, then I'll add these to the list of candidates to ship out.

Quote:

Quote: More after this break... Just one more thing. As usual, "code reviews" are just chances for improving your "code". Final decisions are always yours.

Sure, though constructive criticism is always welcome.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: cdimauro wrote: It's also for not repeating the mistake that Motorola did with the 68000, where DBcc instructions have only a 16-bit counter. Just use the same size of the register and you're "future proof". I think using a signed full register width makes sense when the comparisons with the value are in fact always going to be around zero in this case. Realistically it's going to come down to "branch if not zero" and "branch if not negative", since we are decrementing. Technically, I suppose you could have "branch if negative" that would catch the sign wrap around. I wouldn't want to wait that one out

Hum. I was thinking that we can have signed or unsigned counters. So, two different DBcc instructions are possible. However the more general is the unsigned one (the signed one can be "converted" to unsigned, with a branch & test operation to check if the content is positive).
Quote:

Quote: Indeed. I haven't reported it because I didn't want to overload the review with too many things, but the idea is the same (with the usual main goal to free 16-bit opcodes) because usually conditional branches are short in range, so the 4-bit field could be use to pack together many conditions. As above, I actually don't think there are so many useful conditions to use here. The point about the shorter branch is a good enough case, really. You will note that all other compare-and-branch and the case instruction all use 16-bit offsets, so I'm happy to to drop the 20-bit offset here and reserve the bits for something else. One thing might be to permute the instruction, itself. For example, you could use the 4-bit value to encode a decrement step in a range 1-16 if all you want is just DBNZ. Or you could use it to implement varying integer sizes, e.g. dbnz.i8 and such. I don't want to add too much conditional logic to the implementation of the operation of course.

Then maybe it's better to don't use the 4-bit field (SBZ). Maybe a better idea comes, and you can reuse it accordingly.
Quote:

Quote: BTW, on your ISA you miss a 8-bit conditional jump instructions, but due to the missing condition codes register this is practically impossible to implement because of the lack of space. BEQ_8, BGR_I8, BGREQ_I8 are all enumerated and BNZ supports 8 bit too. Do you mean short branch displacement versions?

Yes, I was talking about the short branch displacement.
Quote:

Quote: LD_II, ST_II - offset by the 32-bit signed index value in I * Should be 32-bit for 32-bit ISA and 64-bit for 64-bit ISA. - Scale value is applied as a shift, meaning the largest scale factor possible is 32768. * A so big scale value is rarely used. 1x to 8x makes more sense. And you can use the two free bits to define a small offset (which is always useful) I'll consider this but I want to avoid multiplication for the sake of simplicity on low end targets, e.g. 68K. I agree the larger offsets won't be used much, but I have implemented stuff that breaks down 2D maps and such into 4KiB data chunks. A big shift is handy for that sort of thing.

I think that it's all about how much common it is.

From my experience (on general-purpose code), an offset (even small) is quite frequent. With 2 bits you can have only 4 values (which can, more conveniently, be shifted by size).

Big shifts aren't that common.

However we talk about two different types of code (general-purpose vs 2D maps).
Quote:

Quote: MV_x - The value in S is copied to the D. Where the operation size is less than the register size, the upper bits of the register are not affected. * Just define a single MOV instruction for integer registers and another one for floating point registers: moving small portions of registers aren't so frequent instruction to justify a specific opcode. If you think that it's really important, you can define an extended opcode for it. It's probably the 68K coder in me that wants to keep this. If I discover a set of new opcodes I definitely want to bring into the core set, then I'll add these to the list of candidates to ship out.

Yes, I don't say to completely suppress them.

On my ISA I've a very short (16-bit) opcode for moving an entire integer register, and another one for a SIMD/vector register. That's because those are the absolutely more common cases found in the real code.

However moves with smaller register size is still possible, but have a longer opcode (32-bit).