ZORRAM

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

@MEGA_RJ_MICAL

Thanks for aligning the thread back to a 4 post boundary.

_________________
Doing stupid things for fun...

@Karlos

0002 - Bus Error

_________________
"Unix is supposed to fix that." -- Jay Miner

Quote:

Karlos wrote: @MEGA_RJ_MICAL Thanks for aligning the thread back to a 4 post boundary.

NOW TO SORT OUT THAT PESKY ENDIANNESS

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

@cdimauro

Before writing a single line of code, I'm just going to make it clear that this is all your fault...

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro Before writing a single line of code, I'm just going to make it clear that this is all your fault...

You could also consider adding a set of FMA instructions (only for FP instructions).

@cdimauro

https://github.com/0xABADCAFE/exvm2/blob/main/docs/pdf/ExVM2_Base_Instruction_Set.pdf

All opcodes 0-237 assigned, 238, 239 unusued, 240-255 reserved for extension sets.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro https://github.com/0xABADCAFE/exvm2/blob/main/docs/pdf/ExVM2_Base_Instruction_Set.pdf All opcodes 0-237 assigned, 238, 239 unusued, 240-255 reserved for extension sets.

OK, thanks. I'll take a look once I've some time, and give feedback, if I've something.

@cdimauro

I'm going to start prototyping it when I get a minute to myself. Unlike the first version that was written first on 680x0 and basically extended out to other architecture, I'll probably just start on x64 and stick with it for now, though I do want to keep it portable in the same way.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro I'm going to start prototyping it when I get a minute to myself. Unlike the first version that was written first on 680x0 and basically extended out to other architecture, I'll probably just start on x64 and stick with it for now, though I do want to keep it portable in the same way.

I don't see a problem, unless you want to write it in x64 assembly (which, BTW, doesn't work on Visual Studio: Microsoft never added inline assembly support for any other ISA after x86. Assembly code should stay on separate assembly files, and compiled as objects with MASM or other assemblers).

So, it should be enough to just wrap endianess-sensible code to a few macros (that's what I did with WPython, my CPython fork).
You have only a few opcode formats, so it should be easy and efficient.

@cdimauro

I'd have to learn x64 assembly first, lol. I used some pretty simple macros to ensure portability last time, the same should work this time. I don't want to over rely on macros where idiomatic modern C++ can fix things though, e.g. if constexpr driven code. It was liberating to get rid of most of the macros I'd used in MC64K and replace with clean code.

_________________
Doing stupid things for fun...

@Karlos


So you could prototype a Uber 68000 and 680x0 compatible virtual CPU? Maybe do the UBER Hack.. Prototype a x86 and ARM and 68000 and maybe even PPC compatible virtual machine? So to speak the all worlds compatible virtual Machine? Is that possible?
I am the crazy guy.. you are the Genius.. *lol*

To create an Uber Virtual Machine were you can run all existing Worlfd.. Mac Windows Linux and classic and NG Amiga?

I know there are people who wouldn`t like it a machine were you can run absolutley everything hahahahahha

I think that would even cause trouble *lol*

Maybe that was the Reason why Commodore really went Bankrupt The Amiga X000 already were such kind of machines! Amiga was documented and in any way hackable!
The Computer World of today wants as much silly consumers as possible!

Last edited by QBit on 30-May-2022 at 04:22 PM.
Last edited by QBit on 30-May-2022 at 04:19 PM.
Last edited by QBit on 30-May-2022 at 04:18 PM.
Last edited by QBit on 30-May-2022 at 04:14 PM.
Last edited by QBit on 30-May-2022 at 04:13 PM.
Last edited by QBit on 30-May-2022 at 04:12 PM.
Last edited by QBit on 30-May-2022 at 04:11 PM.
Last edited by QBit on 30-May-2022 at 04:05 PM.
Last edited by QBit on 30-May-2022 at 04:04 PM.
Last edited by QBit on 30-May-2022 at 04:02 PM.
Last edited by QBit on 30-May-2022 at 04:01 PM.

@QBit

You can build a virtual machine to do anything. The only hard requirement is that the host has the same overall Turing completeness as the thing being virtualised. However, in terms of practical requirements, you want something to be usable. You could, with some extreme effort, emulate an x64 on a 68000, using for example, custom hard disk paging etc to emulate a 64 bit address space despite only being in a 32-bit processing context. However, it would be glacially slow to do in practise.

My experience is that good quality interpretive machines typically run at around 10-20% of equivalent native performance of the host hardware. It's difficult to measure though, when you are comparing a machine that has no real-world existence to one that does. Neither exvm or MC64K are emulations of "real" machines. Their performance is therefore... their performance. Until I write a JIT they won't get much better.

_________________
Doing stupid things for fun...

@Karlos


What if i won the Lottery and offered you such a Monster:

https://www.gekko-computer.de/Dell-Workstation-Precision-7920-2x-14C-Xeon-Gold-6132-2-6GHz-64GB-512GB-SSD.html

Or other way asked:
If you had 4000 € what would YOU buy for Hardware?

Last edited by QBit on 30-May-2022 at 04:56 PM.

@QBit

For what purpose, exactly? I am not sure I'd spend 4000 EUR for my day to day computing needs just now.

If you want "monster" 68K performance right now, UAE has you covered on a machine half as powerful as the above.

I wrote MC64K because I wanted to write assembly language style code in a reasonably familiar syntax. It's not a 64-bit 68000 "emulator".

Last edited by Karlos on 30-May-2022 at 05:06 PM.
Last edited by Karlos on 30-May-2022 at 05:05 PM.

_________________
Doing stupid things for fun...

@all

I sent 20 € to kalamatee. AROS was OK!

@Karlos

Quote:

Karlos wrote: @cdimauro I'd have to learn x64 assembly first, lol. I used some pretty simple macros to ensure portability last time, the same should work this time. I don't want to over rely on macros where idiomatic modern C++ can fix things though, e.g. if constexpr driven code. It was liberating to get rid of most of the macros I'd used in MC64K and replace with clean code.

You have only a few opcodes formats, so you need only a limited number of macros.

Or maybe nothing, since for values bigger than 8-bit you use the same endianess of the host system.

Follow is my feedback about the v2 draft

===============================================

Pag.3
Register Stack should be:
Pointer, mutable, host address size aligned
according to t is always aligned to the full register width

General hints for instructions (- is your writing. * is mine):
- Where the operation size is less than the register size, the upper bits of the register are not affected.
* it's more useful to either sign or zero-extend the the result in this case. Both have pros and cons.
x64 zero-extend it, because it's easier to implement in hardware.
Anyway, the rational for extending the result to the register size is to don't have stalls in the pipeline due to the partial access to a register (and subsequent accesses to the entire register).

ABS_x, CEIL_x, FLOOR_x
* maybe it could be moved to the extended opcode space, since it's a rarely used instruction. This will free some useful slots on the opcode space.
* You might allocate a specific opcode on the extended opcode space, for monadic instructions which are rarely used.

ADDQ, LSLQ, LSRQ, SUBQ
- The immediate is in the range 0-16
* it should 1-16 (with 16 being mapped as zero)

BCALL_8
* Calls to subroutines aren't so frequent to justify a specific opcode for this. You might BCALL_24 to BCALL, and just use it.

BRK
- Note that this should be opcode zero, such that any unintended branch to zero filled memory will be
interpreted as a break #0.
* It's better to reserve opcode zero for illegal instructions. Otherwise when breakpoints are triggered, you don't know if it was caused by an application fault or a by triggering a breakpoint.
* Some architectures define an "all-ones" opcode (0xffff in your case) for the same reason. But this will ruin the last opcodes that you've reserved.

DBNZ
- Decrement the 32-bit integer value in D.
* This should 32-bit for 32-bit ISA and 64-bit for 64-bit ISA
- The most significant 16-bit portion of a 20-bit displacement is stored in the extension word as this can be sign expanded with branchless logic.
* Loops are usually small, so thi instruction don't require a so bit offset (20 bits!). You might use the the 4 bits to map different types of branches which use a register as argument; or you might fuse this instruction with DBNN (by using #d = 0).

DSA
* Consider to introduce a compact version (16-bit) using a 4-bit immediate which is scaled by the register size. This kind of instruction is very common on function/methods prologues, and will contribute to improve the code density

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.

LDI
* Consider to use a version which loads an FP16 and expands it to FP32 or FP64. This will improve the code density.
* It would be good for all other load operations, but you've a limited opcode space, so currently it's not possible.

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)

FMOD_x, POW_x
* maybe it could be moved to the extended opcode space, since it's a rarely used instruction. This will free some useful slots on the opcode space.

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.

RET
- It is possible to return from an
entire call tree up to a maximum depth of 256 by specifying the optional depth parameter.
* I don't know how much useful it could be. A simple RET instruction should be enough.

ST_II
- The value at the effective address computed by taking the base address in B, offset by the 32-bit signed index value in I, scaled by shifting with integer value N, is loaded into D
* This is the definition the LD_II, but this is the store one.

x_2_F32
- Conversion of 64-bit integer values to floating point may result in loss of precision.
* This can happen with 32-bit integers as well


*** Ternary Extension ***
You can also consider to use one opcode to extend the instructions to Dyadic (ternary operators: two sources and one destination), which works exactly like the current opcodes, but uses the additional source register as the second source. Possible layout of these ternary instructions: the extended word is exactly like the normal/main opcode, but the main opcode holds the second source in the field of the source operand (and the destination operand field is left unused).

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

Multi depth return is just something that I figured could make use of the fact the return stack is separate and the opcode byte isn't used otherwise. I do have example code that recurses in steps of known size (e.g. each step may be a fixed number if calls deep) that could benefit from multi level return. Obviously this only makes sense where there are no other stack parameters.

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.

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.

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.

More after this break...

Last edited by Karlos on 30-May-2022 at 10:35 PM.
Last edited by Karlos on 30-May-2022 at 10:30 PM.

_________________
Doing stupid things for fun...

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

Multi depth return is just something that I figured could make use of the fact the return stack is separate and the opcode byte isn't used otherwise. I do have example code that recurses in steps of known size (e.g. each step may be a fixed number if calls deep) that could benefit from multi level return. 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.
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".
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.

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

PADDING!!!!!!!!!!!!!!!

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