Click Here
home features news forums classifieds faqs links search
6076 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
68 crawler(s) on-line.
 18 guest(s) on-line.
 1 member(s) on-line.


 BigD

You are an anonymous user.
Register Now!
 BigD:  2 mins ago
 jacadcaps:  7 mins ago
 Rob:  35 mins ago
 Karlos:  35 mins ago
 miggymac:  38 mins ago
 Comi:  1 hr 24 mins ago
 zipper:  1 hr 26 mins ago
 NutsAboutAmiga:  1 hr 36 mins ago
 jorkany:  1 hr 40 mins ago
 VooDoo:  1 hr 48 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 Next Page )
PosterThread
ferrels 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 3:28:49
#41 ]
Cult Member
Joined: 20-Oct-2005
Posts: 884
From: Arizona

@MEGA_RJ_MICAL

Fabbing tires and rims and fabbing ASICs, it's all the same right? Just some simple tooling changes and he'll have the $35 ASIC ready in no time.





 Status: Offline
Profile     Report this post  
kolla 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 3:41:53
#42 ]
Elite Member
Joined: 21-Aug-2003
Posts: 2088
From: Trondheim, Norway

@matthey

Quote:
Why does THEA500 need a 1-2GHz CPU with 256MiB of memory to emulate an Amiga 500 with 7MHz 68000 and 1MiB of memory?


Because an Amiga A500 also has a chipset that needs be emulated. As I have written to you many times now.

You want to replace the 68k with a new ASIC. Great. Lets move on. How about the rest, the Amiga chipset, I/O how will you implement that on this SoC of yours so that it will actually be compatible with the old software you wish to run?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 5:32:27
#43 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2482
From: Germany

@kolla: and it should 100% Amiga compatible, since "looks like" that emulation isn't enough accurate.

 Status: Offline
Profile     Report this post  
MEGA_RJ_MICAL 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 5:54:02
#44 ]
Cult Member
Joined: 13-Dec-2019
Posts: 845
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

Friend ferrels!

Look at all that RISC!!!!!!!!!!

Rims
In
Scrappy
Courtyard

/m-m-mega



Quote:

ferrels wrote:
@MEGA_RJ_MICAL

Fabbing tires and rims and fabbing ASICs, it's all the same right? Just some simple tooling changes and he'll have the $35 ASIC ready in no time.





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

 Status: Offline
Profile     Report this post  
QBit 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 6:00:05
#45 ]
Regular Member
Joined: 15-Jun-2018
Posts: 202
From: Unknown

@all
Amiga Pistorm EMU68 how to plus more!
https://www.youtube.com/watch?v=tw6IG1cOxWc



 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 9:05:49
#46 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12145
From: Norway

@ferrels, @MEGA_RJ_MICAL

So "scrapyard" become "Scrappy Courtyard" to fit your narrative. I hate to play word scramble with you.

Lets inquire more into this subject here.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44537&forum=2

Last edited by NutsAboutAmiga on 16-May-2022 at 09:31 AM.
Last edited by NutsAboutAmiga on 16-May-2022 at 09:08 AM.
Last edited by NutsAboutAmiga on 16-May-2022 at 09:06 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Karlos 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 9:23:00
#47 ]
Elite Member
Joined: 24-Aug-2003
Posts: 2478
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

This got weird fast.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
MEGA_RJ_MICAL 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 10:35:05
#48 ]
Cult Member
Joined: 13-Dec-2019
Posts: 845
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

@Karlos

AMIGA RACER

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

 Status: Offline
Profile     Report this post  
tlosm 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 11:20:42
#49 ]
Elite Member
Joined: 28-Jul-2012
Posts: 2722
From: Amiga land

@kolla

i buy a mini 500 and is a cool dongle.
It emaulate really good the amiga series. It gave me 250 mips in sysinfo and is aga compatible.
I test doom and heretic and fears and all 3d games and run really really fast and good.
i will make a test with quake and quakeii.
I made a fast test with shapeshifter and it work
In workbech i have 8 mb of chip and 144mb of fast.
Emulation of 040 with fpu mmu.

only bad think is little slower in loading from the usb. but i have to check some other pendrive and hadfile .

It is a good alternative if you dont wanna turn on the real classic amiga and it work with only 5v usb.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

 Status: Offline
Profile     Report this post  
Karlos 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 11:23:50
#50 ]
Elite Member
Joined: 24-Aug-2003
Posts: 2478
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

Quote:

@Karlos

Quote:

Karlos wrote:
This conversation is giving me the itch to update exvm lol.

Good. You can make it more general-purpose & complete.

And you can better use the opcode space to make instructions more compact or open new "slots" for more instructions.


So, getting back to a sensible conversation, I have some thoughts on this.

1. Create a separate register file for floating point.
2. Add corresponding load/store operations for floating point.

A design choice originally was that the raw opcode byte would always imply the operand type. This has resulted in the simplest possible fetch/decode cycle but has increased the base opcode count. We can reduce the opcode enumeration for the following:

ADDI (Add immediate): Encode the operand type in the unused source operand nybble, saving up to 5 opcode slots as we can include floating point too.
BNZ (Branch if not zero): Encode the operand type in the unused source operand nybble, saving 3 opcode slots (no point in adding explicit floating point as it's an all bits zero test).

BCALL (PC relative call): Increase 16-bit displacement to 24 bits.

BRK (Break): Add an 8 bit identifier for the breakpoint.

CALL, ICALL, CALLN, ICALLN (Call / Call Native): Encode the call type (direct, indirect, native direct, native indirect) into the unused src nybble, saving 3 opcode slots.

LD_I16, LDI_32 (Load Immediate): Encode the operand type into the unused source operand nybble, saving up to 7 opcode slots.

PUSH/POP: Encode the operand type (size alone is no longer sufficient if there is a separate FP register file) into the unused destination operand nybble. Additionally, can add an optional alignment hint in the unused source operand nybble. Saves up to 10 opcode slots.

RET (Return): Optional return depth in unused byte. The return stack is completely separate from other stacks so we can in theory do returns from a greater depth in one step.

SALLOC (Stack Allocate): Add alignment hint in the unused source operand nybble.

Just a few thoughts.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
QBit 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 11:32:06
#51 ]
Regular Member
Joined: 15-Jun-2018
Posts: 202
From: Unknown

@Karlos


If it is possible to code a virtual 64 Bit 680x0 CPU then it would be possible to code
virtual 64 Bit Multithreaded 68xxx CPU! And Virtual GPU and a virtual 24 Bit
Amiga Sound with 192 khz!

I just have no skills to do it.. but am I wrong?

Last edited by QBit on 16-May-2022 at 11:33 AM.

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

@QBit

Quote:

QBit wrote:
@Karlos

If it is possible to code a virtual 64 Bit 680x0 CPU then it would be possible to code
virtual 64 Bit Multithreaded 68xxx CPU!


Just to be clear, MC64K is not a virtual 680x0; there's no binary compatibility at all. However, it would be entirely possible to take the 680x0 ISA and design a 64-bit virtual machine around that. There are definitely challenges around making it backwards compatible with 32-bit binaries, but it's definitely doable.

Same with multicore. At the very least, you could spin up separate native threads (sharing the same memory space for simplicity), each with their own effective machine state but otherwise same access to memory. This is something I am considering for MC64K.


Quote:
And Virtual GPU and a virtual 24 Bit
Amiga Sound with 192 khz!

I just have no skills to do it.. but am I wrong?


No. You are only limited by what the host environment can do with the processing resources available. For example, if your native sound output is limited to 48kHz, then 192kHz is still possible for internal mixing and signal processing but in the end you are going to have to downsample for actual playback. This could sound better than doing everything at 48kHz, but in all probability I doubt you'd notice.

MC64K currently has the most basic imaginable frame buffer display but it is/can:
* Show various colour depths up to 24-bit RGB
* Be larger than the visible display and be scrolled accordingly.
* Perform some basic COPPER like effects (gradients, messing with other display registers).

These are all handled purely in software on the host. I use OpenGL for scaling lower virtual resolutions to a more comfortable size only.

A "proper" virtual GPU is something you'd probably design as an API implemented using Vulkan of OpenGL.

Last edited by Karlos on 16-May-2022 at 12:23 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 18:29:47
#53 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2482
From: Germany

@Karlos

Quote:

Karlos wrote:
@cdimauro

[quote]So, getting back to a sensible conversation, I have some thoughts on this.

Nice.
Quote:
1. Create a separate register file for floating point.

Have you consider to add support for SIMD/Vector (length-agnostic)? If yes, you might use the same register set for FP instructions, which will just be the scalar ones, whereas the SIMD/vector instructions will be the packed ones (using the entire register size).

This is how SSE/AVX/AVX-512 are defined on x86/x64 (the old x87 is still there with its 8 registers, but it's deprecated).

On my ISA I've a fully orthogonal SIMD/Vector unit, which where any instruction can be:
- scalar or packed;
- integer or FP;
- 8, 16, 32, 64-bit for integers or 16, 32, 64, and 128-bit for FP.

You might consider to have 4-bit field which encodes that above information on the first word, leaving the second word for defining the opcode and operands. This is just for example, to have a more homogeneous opcodes encoding.
Quote:
2. Add corresponding load/store operations for floating point.

You might define as well some instructions for saving/restoring the full FPU/SIMD/Vector registers set (like XSAVE/XRESTORE on x86/x64).

And since you like 3D engines, you might consider to add gather / scatter instructions as well.
Quote:
A design choice originally was that the raw opcode byte would always imply the operand type. This has resulted in the simplest possible fetch/decode cycle but has increased the base opcode count. We can reduce the opcode enumeration for the following:

ADDI (Add immediate): Encode the operand type in the unused source operand nybble, saving up to 5 opcode slots as we can include floating point too.

You might consider to drop 8 and 16 bits support for general purpose / "integer" instructions.

On x64 the most used instructions are 32 and 64 bit: there are very little cases where 8 or 16-bit are used. That's why I've optimized (read: selected proper short opcodes) my ISA only for those two sizes.

On x86 the most used are 32 and 8 bits, and little cases for 16-bit. This is because it's an old ISA, so there's a lot of code and optimizations which used 8 bits, and they are still carried on even nowadays.

I suggest you to consider to limit GP instructions only to 32 and 64-bits, at least for the more compact opcodes, in order to reduce and better use the 16-bit opcodes spaces (which IMO is the most important, since it's the one which strongly influences the code density).

If you still want to keep supporting 8 and 16 bit you might do it in the extended instructions sets. Which is what I've done with my ISA: longer opcodes for more general/generic instructions.
Quote:
BCALL (PC relative call): Increase 16-bit displacement to 24 bits.

That's nice: I've done the same with my ISA, where the short versions of CALL and JMP use a 24 bit offset (and longer ones use 40 bits). This allows you to reach much more routines without requiring to resort to bigger opcodes.

Since you ISA has opcodes which are multiple of 16-bits, then I suggest you to scale this offset by 2, so giving an effective 25 bits offset. That's what I've done with my ISA:
Quote:
BRK (Break): Add an 8 bit identifier for the breakpoint.

I don't think that its useful. And 8 bit identifier might be more useful on a SYSCALL instructions, but 256 possible o.s. APIs aren't that much.
Quote:
PUSH/POP: Encode the operand type (size alone is no longer sufficient if there is a separate FP register file) into the unused destination operand nybble. Additionally, can add an optional alignment hint in the unused source operand nybble. Saves up to 10 opcode slots.

On my ISA I've defined on a general status registers the minimum size for data pushed into the stack, so this has solved alignment problems.

You don't need to encode it on PUSH/POP instructions, because this is a waste of space, since those alignment requirements are always the same.

All those details (and much more) are defined on a specific general status register on my ISA, for this reason. Basically I can "configure/retarget" my ISA defining there some options, so that instructions are optimized for the specific applications which is being executed (every app has its own general status registers defined on the executable info).
Quote:
RET (Return): Optional return depth in unused byte. The return stack is completely separate from other stacks so we can in theory do returns from a greater depth in one step.

I don't see it useful.
Quote:
SALLOC (Stack Allocate): Add alignment hint in the unused source operand nybble.

See above for PUSH/POP: not needed.

You might better consider to define a short version of this instruction, which has no immediate on the second word. You can define a 4 bit immediate which is scaled by the stack alignment (defined on the above general status registers). So if you have, for example, a 4 byte alignment, then you have 4, 8, 12, ... 64 (which is encoded as 0) immediate.

This is much more useful and used on real code, and improves considerably the code density.
Quote:
Just a few thoughts.

Same for me.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 19:14:17
#54 ]
Elite Member
Joined: 24-Aug-2003
Posts: 2478
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

Still drafting it out. SIMD wise, I've not done anything yet. The extended streaming opcodes are still all as they are. What I am doing first is to see how I can compact the base instruction set as much as possible without increasing complexity in the interpreter or for a JIT. Depending by how much the core instruction set contracts, the next step is to work out which additional instructions are nice to have within it.

The current ocpode draft is here.

Quote:
On my ISA I've defined on a general status registers the minimum size for data pushed into the stack, so this has solved alignment problems.

You don't need to encode it on PUSH/POP instructions, because this is a waste of space, since those alignment requirements are always the same.


Just for clarity, in exvm there are two independent data stacks. A generic data stack for arbitrary passing of varying type data, and a register save/restore stack for spilling. The latter is always aligned.

Quote:
Since you ISA has opcodes which are multiple of 16-bits, then I suggest you to scale this offset by 2, so giving an effective 25 bits offset. That's what I've done with my ISA


Technically it already is; the displacement value is measured in "words".

-edit-

There are now 228 defined core opcodes according to my calculations. I have reintroduced the load and store register indirect with scaled index back which were previously in an extension set.

Last edited by Karlos on 16-May-2022 at 08:16 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 20:23:20
#55 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2482
From: Germany

@Karlos

Quote:

Karlos wrote:
@cdimauro

Still drafting it out. SIMD wise, I've not done anything yet. The extended streaming opcodes are still all as they are.

np. Just save some opcode space for them, because they require some.

Well, it primarily depends on how many SIMD ternary instructions you want to define. At least on the most compact opcode space. Longer opcodes spaces will definitely solve the problem. However your current ISA has only 16 or 32-bit opcode sizes.
Quote:
What I am doing first is to see how I can compact the base instruction set as much as possible without increasing complexity in the interpreter or for a JIT. Depending by how much the core instruction set contracts, the next step is to work out which additional instructions are nice to have within it.

Yes, the 16-bit opcode space is crucial: it's better that you focus on it.
Quote:
The current ocpode draft is here.

OK
Quote:
Quote:
On my ISA I've defined on a general status registers the minimum size for data pushed into the stack, so this has solved alignment problems.

You don't need to encode it on PUSH/POP instructions, because this is a waste of space, since those alignment requirements are always the same.


Just for clarity, in exvm there are two independent data stacks. A generic data stack for arbitrary passing of varying type data, and a register save/restore stack for spilling. The latter is always aligned.

Yes, I saw that you've 3 stacks. I was referring to the one for registers passing / local data storage.
Quote:
Quote:
SALLOC (Stack Allocate): Add alignment hint in the unused source operand nybble.


I may get rid of this anyway, I can't remember what I was suppose to be using it for.

It looks like the classic:

MOV RBP,RSP
ADD RSP,Immediate

on x64, and it's used to create a stack frame in functions' (calls) prologues.

It's very important for high-level languages: better to keep it.

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

@cdimauro

The stack allocate/deallocate logic was really for creating local stack frame storage that could be accessed using register indirect modes. As there's no other way to actually modify the stack (apart from pushing and popping), then yes, it's probably better to keep it. I think the core instruction set is OK for now. As it stands, opcodes 240-255 are technically reserved for 16 extension sets of 256 operations each. I would hope that's sufficient for all the streaming and other more complex operations I haven't thought of for now.

I might even reserve them by data type, e.g.

249: 8-bit integer stream
250: 16-bit integer stream
251: 32-bit integer stream
252: 64-bit integer stream
253: 16-bit float stream
254: 32-bit float stream
255: 64-bit float stream

I don't think I want to try and implement an actual register based SIMD unit because at least for the interpreter the fetch/decode/execute overhead renders the gains minimal (unless very wide).

So that leaves me with ten free opcode slots in the base instruction set for anything else. For myself, an obvious few are:

* countdown (i.e. dbnz)
* list traversal (load indirect and branch if not null)
* multiply-accumulate (probably just for floating point)
* floating point check and branch (e.g. source nybble encodes a class like +INF, -INF, NAN and the destination is tested against the class)

Last edited by Karlos on 16-May-2022 at 08:56 PM.
Last edited by Karlos on 16-May-2022 at 08:50 PM.
Last edited by Karlos on 16-May-2022 at 08:43 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 21:02:23
#57 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2482
From: Germany

@Karlos

Quote:

Karlos wrote:
@cdimauro

I think the core instruction set is OK for now. As it stands, opcodes 240-255 are technically reserved for 16 extension sets of 256 operations each. I would hope that's sufficient for all the streaming and other more complex operations I haven't thought of for now.

They look not enough: the encoding space for vector stuff is the one which usually takes the most.

Try to reserve more space by moving some less used instructions on the extended format.

On my ISA I've reserved around 40% of the opcode space for compact (16-bit) encodings, and the rest split more or less equally between the GP and SIMD/Vector encodings.

But this is my design: different ISAs have different arrangements, according to the specific design constraints.
Quote:
So that leaves me with ten free opcode slots in the base instruction set for anything else. For myself, an obvious few are:

* countdown (i.e. dbnz)

For this I've decided to don't add it, because it's complicated for implementations. I've only left the test & branch. For this reason I've moved to millicode instructions the LOOP instructions on x86/x64.
Quote:
* multiply-accumulate (probably just for floating point)

Yes, FP is enough.
Quote:
* floating point check and branch (e.g. source nybble encodes a class like +INF, -INF, NAN and the destination is tested against the class)

Have you defined 32 different conditions for FP values? Because this is what's found on x86/x64 (on the SIMD comparisons instructions).

 Status: Offline
Profile     Report this post  
Karlos 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 21:14:48
#58 ]
Elite Member
Joined: 24-Aug-2003
Posts: 2478
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

SIMD isn't as high on my priority list as decent general-purpose performance and portability. After all, it still runs on 68K and pre-altivec PPC among other processors. If you recall, the vector extensions it has are really just array processing that can be implemented on scalar and improved on SIMD. I don't plan on mapping the whole of AVX or anything as ambitious as that.

I think there's less wastage in the opcode layout now, even if some opcodes are now more complex (e.g. there's a field to decode where previously that field would've actually been a range within the opcode byte). The first extension set actually had some useful things moved into it originally when I hit the reserved 240-255 range that can come back now, eg. the load/store indexed.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
BigD 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 16-May-2022 22:31:48
#59 ]
Elite Member
Joined: 11-Aug-2005
Posts: 6309
From: UK

@ferrels

I saw the photo of the commercial unit and first thought AmigaKit were diversifying following the falling out with Hyperion and A1222 Plus delays

AmigaKit:
"Tyres, wheel hubs, replacement components for computer OSes, Amiga mice! You name it, we engineer it in a unit on Dyfrig Road!"

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Online!
Profile     Report this post  
cdimauro 
Re: Virtual machines, instruction sets, that sort of thing...
Posted on 17-May-2022 5:22:19
#60 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2482
From: Germany

@Karlos

Quote:

Karlos wrote:
@cdimauro

As it stands, opcodes 240-255 are technically reserved for 16 extension sets of 256 operations each. I would hope that's sufficient for all the streaming and other more complex operations I haven't thought of for now.

I might even reserve them by data type, e.g.

249: 8-bit integer stream
250: 16-bit integer stream
251: 32-bit integer stream
252: 64-bit integer stream
253: 16-bit float stream
254: 32-bit float stream
255: 64-bit float stream

Consider to reserve one for 128-bit float stream. FP128 is the next big thing which will come in some years.
Quote:
I don't think I want to try and implement an actual register based SIMD unit because at least for the interpreter the fetch/decode/execute overhead renders the gains minimal (unless very wide).

Quote:
SIMD isn't as high on my priority list as decent general-purpose performance and portability. After all, it still runs on 68K and pre-altivec PPC among other processors.

OK, but only pay attention that the SIMD/vector unit is the most important part of modern processors, for performances reasons.

So, you might leave it out now, but in future you've to think about how your ISA behaves with the vectorized/able code and compare it with other ISAs to see how good it is in that field.
Quote:
If you recall, the vector extensions it has are really just array processing that can be implemented on scalar and improved on SIMD. I don't plan on mapping the whole of AVX or anything as ambitious as that.

Yes, I recall.

You don't need to map all AVX (your ISA doesn't have this constraint. Only mine has it, because it's a x86/x64 superset): it's enough to provide the most important vector instructions.

BTW you already have even more sometimes, with ASIN, ACOS, etc. instructions.
Quote:
I think there's less wastage in the opcode layout now, even if some opcodes are now more complex (e.g. there's a field to decode where previously that field would've actually been a range within the opcode byte). The first extension set actually had some useful things moved into it originally when I hit the reserved 240-255 range that can come back now, eg. the load/store indexed.

It should be enough for the second version of you ISA. You already changed several things, and you still have left some "open doors".

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

[ 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