Click Here
home features news forums classifieds faqs links search
6054 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
58 crawler(s) on-line.
 9 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 THRIVECoworkingCumming:  5 mins ago
 JKD:  5 mins ago
 tygre:  2 hrs 4 mins ago
 dalek:  2 hrs 18 mins ago
 Trekiej:  3 hrs 1 min ago
 Hypex:  3 hrs 53 mins ago
 eliyahu:  4 hrs 10 mins ago
 dframeli:  4 hrs 15 mins ago
 Karlos:  4 hrs 22 mins ago
 MEGA_RJ_MICAL:  4 hrs 26 mins ago

/  Forum Index
   /  General Technology (No Console Threads)
      /  Virtual machines, instruction sets, that sort of thing...
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )
PosterThread
MEGA_RJ_MICAL 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 31-May-2022 5:52:38
#101 ]
Cult Member
Joined: 13-Dec-2019
Posts: 905
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

ZORRAM

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

 Status: Offline
Profile     Report this post  
Karlos 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 31-May-2022 12:56:38
#102 ]
Elite Member
Joined: 24-Aug-2003
Posts: 2642
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@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...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 31-May-2022 22:33:42
#103 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2541
From: Germany

@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).

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle