@Karlos

Quote:

Karlos wrote: @cdimauro The 32 bit decision was a simplification originally since theres one way to represent a fixed displacement and read it in from the instruction stream. It wasn't chosen specifically to waste space and was tolerable in cases where you typically only have one such operand in a statement. However, there are free EA slots and encoding integers into smaller representations is a solved problem for immediates already. So it seems like a worthwhile time to do it.

That's the reason why, if you remember, my first comment about your architecture was that it had poor code density.
Quote:

Karlos wrote: @cdimauro There are currently exactly 32 unused EA enumeration values and 16 registers. There are two indirect modes that support a displacement (not including the PC variant). It seems like my unconscious mind was keeping those slots free for this exact purpose.

So, it looks like that you could have register indirect modes with 8, 16, and 32-bit displacements.

Paired with equivalent modes for PC variants and it's perfect.

@cdimauro

Sure but I think code density applies more strongly to physical hardware than it does byte code interpretation.

_________________
Doing stupid things for fun...

@Karlos: yes. But once you or someone else decides to make an hardware implementation, then it matters.

In the meanwhile you can already see how good it performs on this very important metric.

@cdimauro

They'd have to be nuts to do that ;)

In any event, if we want an optimum code density ISA for a modernised 64-bit reincarnation of the 68000 that maintains total backwards compatibility with existing object code, there's already someone here with the plan...

Last edited by Karlos on 15-Oct-2022 at 04:58 PM.

_________________
Doing stupid things for fun...

@Karlos: yes, I know. But your architecture (as well as mine) is a new one: just inspired to 68k.

Which is good, because you don't have to reproduce / keep all its issue and you've more freedom for implementing new stuff (as you're doing).

@cdimauro

I don't have any ambition to make a hardware realisation but if I did, I'm sure I'd pay a lot more attention to how the opcode is arranged and reconsider having a CCR. What I do want to do at some point however is have a native code translator, either JIT or AOT.

Last edited by Karlos on 15-Oct-2022 at 05:22 PM.

_________________
Doing stupid things for fun...

Well, that's done. For regular d(An) / d(An, Xn*size) modes, whenever d is in the range -128 to 127, a byte representation is used. This required the reservation of all 32 remaining EA enumeration values, so larger displacements will continue to use 32-bit representations.

As expected it hasn't made a significant difference in interpretation throughput, but it does result in smaller code wherever fixed displacement EA modes are used.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro I don't have any ambition to make a hardware realisation but if I did, I'm sure I'd pay a lot more attention to how the opcode is arranged and reconsider having a CCR.

Indeed. Actually your ISA is tailed for software / VM implementation, but an hardware implementation requires a different opcode structure if you want to simplify its decoding.

For example, all EA bytes should be placed just after the main opcode, with their displacements following (if any).
Quote:

What I do want to do at some point however is have a native code translator, either JIT or AOT.

That's OK. I'm a software guy so to me first comes a software implementation (assembler, disassembler, emulator).
Quote:

Karlos wrote: Well, that's done. For regular d(An) / d(An, Xn*size) modes, whenever d is in the range -128 to 127, a byte representation is used. This required the reservation of all 32 remaining EA enumeration values, so larger displacements will continue to use 32-bit representations.

Nice. So you have 8 and 32-bit displacements (and no 16-bit displacements) now using both addressing modes, correct?
Quote:

As expected it hasn't made a significant difference in interpretation throughput, but it does result in smaller code wherever fixed displacement EA modes are used.

@cdimauro

Quote:

cdimauro wrote: @Karlos Indeed. Actually your ISA is tailed for software / VM implementation, but an hardware implementation requires a different opcode structure if you want to simplify its decoding. For example, all EA bytes should be placed just after the main opcode, with their displacements following (if any).

Well, that is actually how it works already. Consider a basic dyadic operation, like move. The first byte is the enumerated opcode (includes the size in the enumeration). The next byte is the enumerated effective address mode for the destination, followed by any data specific to that mode. The next byte is the enumerated effective address mode for the source, followed by any data specific to that mode.

The exception to the above is for opcodes that define register-to-register fast path alternatives. These are just the opcode byte followed by the register pair packed into the next byte.

Quote:

Nice. So you have 8 and 32-bit displacements (and no 16-bit displacements) now using both addressing modes, correct?

Correct.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: cdimauro wrote: @Karlos Indeed. Actually your ISA is tailed for software / VM implementation, but an hardware implementation requires a different opcode structure if you want to simplify its decoding. For example, all EA bytes should be placed just after the main opcode, with their displacements following (if any). Well, that is actually how it works already. Consider a basic dyadic operation, like move. The first byte is the enumerated opcode (includes the size in the enumeration). The next byte is the enumerated effective address mode for the destination, followed by any data specific to that mode. The next byte is the enumerated effective address mode for the source, followed by any data specific to that mode.

This is different from what I've said. Using your example, it is:
- opcode byte(s);
- byte for EA1 mode;
- byte for EA2 mode;
- data/displacement for EA1 mode;
- data/displacement for EA2 mode.
Quote:

The exception to the above is for opcodes that define register-to-register fast path alternatives. These are just the opcode byte followed by the register pair packed into the next byte.

Indeed. It's like the above schema, but with EA1 & EA2 embedded on the same byte.

@cdimauro

Right. I must've misread it. Yep. I did.

So I assume the reason for this is that in hardware you'd want to hand off EA decode as quickly as possible to one or more address units in parallel.

Last edited by Karlos on 16-Oct-2022 at 09:31 AM.

_________________
Doing stupid things for fun...

@MEGA_RJ_MICAL

Quote:

It is, I believe - friend Hypex, a beautiful girl from Italy. as seen here, cosplaying as "Kickstart 1.x Boot Screen"

I think i've found her. The host's definition of her modus operandi fits well "shame, guilt, insult and the need to be right."

https://www.youtube.com/watch?v=E3KPHMoKenE

@Karlos

Quote:

Karlos wrote: @cdimauro So I assume the reason for this is that in hardware you'd want to hand off EA decode as quickly as possible to one or more address units in parallel.

Yes. Especially for very long instructions, which might not fit into the instruction fetch buffer.

For example, you might end-up with the first few bytes of the instruction fetched from that buffer, but those are the most important ones because you can decode everything. When you're able to fetch the remaining data then you already know what was missing and where is located (because you decoded the instruction), so that you can immediately use those missing bytes and execute the instruction without spending other time on decoding.

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Your project is like Virtual Processor (VP) from Tao Group... To borrow the line from Bender Bending Rodriguez, "Oh wait, you're serious? Let me laugh even harder!" I mean it really isn't like that. But let's say it was. What does that have to do with you not being able to run WHDLoad on a ColdFire? I mean the analogy couldn't be worse, really.

For the majority of Amiga users, Bill McEwen's Tao Virtual Processor (VP) was a waste of time.

You can modify Emu68 software (with actual PiStorm/Amiga 500 hardware) to support your instruction set and port AROS to it.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

You keep on making this irrelevant nonsensical comparison.
MC64K is not like VP. It's not a processor that runs an OS. It can't run an OS, as it lacks critical features such as interrupts and supervisor modes. It not an Amiga or Amiga clone. It doesn't run Amiga applications. It's not intended to. No claim to the contrary has ever been made.

It's a programming language environment, like a BASIC interpreter, except that it is low level rather than high for people that like assembly language programming. The syntax and features are inspired by 68K while not being identical.

You may as well say "brainf*uck won't run my WHDLoad collection" and insisting that the interpreter for it is like Taos VP. I mean you're right, it won't run your WHDLoad collection, but neither will a satsuma.

Is it clear enough yet or do you need a picture?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @Hammer You keep on making this irrelevant nonsensical comparison. MC64K is not like VP. It's not a processor that runs an OS. It can't run an OS, as it lacks critical features such as interrupts and supervisor modes. It not an Amiga or Amiga clone. It doesn't run Amiga applications. It's not intended to. No claim to the contrary has ever been made. It's a programming language environment, like a BASIC interpreter, except that it is low level rather than high for people that like assembly language programming. The syntax and features are inspired by 68K while not being identical. You may as well say "brainf*uck won't run my WHDLoad collection" and insisting that the interpreter for it is like Taos VP. I mean you're right, it won't run your WHDLoad collection, but neither will a satsuma. Is it clear enough yet or do you need a picture?

Reminder, this is the Amiga forum. Your project is irrelevant and nonsensical nowhere.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Reminder, this is the Amiga forum. Your project is irrelevant...

It's a forum for Amiga users. Many Amiga users enjoy programming in 68000 assembly language, myself included (though I am a bit rusty).

Frankly from someone that makes long rambling sermons about AMD, I think your complaint about irrelevancy on an Amiga forum is somewhat hypocritical.

Last edited by Karlos on 18-Oct-2022 at 07:48 AM.

_________________
Doing stupid things for fun...

Finally implemented the LINK, UNLK operations, along with the FMACC and FMADD operations suggested previously. Both only accept FPU register operands. This bothers me for a few reasons.

1) fmacc can be replicated by fmadd with almost no loss in efficiency.
2) it may be better to have a version that reads at least one operand from memory, given the sorts of workload multiply accumulate are used for
3) I don't want to trigger anyone into stamping some poor hobo to death while in a febrile rage induced the reduction in code density. I have enough on my conscience as it is.

Last edited by Karlos on 18-Oct-2022 at 06:07 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Reminder, this is the Amiga forum. Your project is irrelevant... It's a forum for Amiga users. Many Amiga users enjoy programming in 68000 assembly language, myself included (though I am a bit rusty). Frankly from someone that makes long rambling sermons about AMD, I think your complaint about irrelevancy on an Amiga forum is somewhat hypocritical.

+2

He doesn't even understand those basic concepts. Embarrassing...

Quote:

Karlos wrote: Finally implemented the LINK, UNLK operations, along with the FMACC and FMADD operations suggested previously. Both only accept FPU register operands. This bothers me for a few reasons. 1) fmacc can be replicated by fmadd with almost no loss in efficiency.

Correct. FMACC is not useful.
Quote:

2) it may be better to have a version that reads at least one operand from memory, given the sorts of workload multiply accumulate are used for

Absolutely. With number crunching algorithms you're reading and processing a lot of data from memory.

Here the reg-mem paradigm of CISC processors makes the difference.
Quote:

3) I don't want to trigger anyone into stamping some poor hobo to death while in a febrile rage induced the reduction in code density. I have enough on my conscience as it is.

No, code density isn't that important in this context. You don't need to find the shortest instructions for implementing FMADD and similar operations.

@cdimauro

I need to put some effort into optimising the EA decode path. It's around 5x slower than the R2R fast path implementation:

Loading object file as host 'Standard Test Host'
Linking 2 exported symbols...
	Matched    0 0x56148cf02cb0 [--x] main
	Matched    1 0x56148cf02d14 [--x] exit
Runtime: Executable instance loaded at 0x56148cf038d0 for binary 'test_projects/bench/bin/bench.64x'
Stack of 256 allocated at 0x56148cf01bd0 ... 0x56148cf01cd0
Beginning run at PC:0x56148cf02cb0...
Benchmarking 10x unrolled using 80000000 iterations
Loop Calibration
	took:    375582962 nanoseconds 213.0022 MIPS 
Baseline: add.q r1, r0
	took:   1038852816 nanoseconds 770.0802 MIPS 1.0000 relative

Benchmarking: add.q r1, (r10)
	took:   5059109489 nanoseconds 158.1306 MIPS 4.8699 relative

Benchmarking: add.q r1, (r10)+/-
	took:   5225708577 nanoseconds 153.0893 MIPS 5.0303 relative

Benchmarking: add.q r1, +/-(r10)
	took:   5285572311 nanoseconds 151.3554 MIPS 5.0879 relative

Benchmarking: add.q r1, 8(r10)
	took:   4999233568 nanoseconds 160.0245 MIPS 4.8123 relative

Benchmarking add.q (r11), (r10)
	took:   5080120650 nanoseconds 157.4766 MIPS 4.8901 relative

Benchmarking: add.q r1, label
	took:   6031763240 nanoseconds 132.6312 MIPS 5.8062 relative

Benchmarking: add.q #1, r0
	took:   5797901749 nanoseconds 137.9810 MIPS 5.5811 relative

Benchmarking: biz.q r0, label (when taken)
	took:   2967526205 nanoseconds 269.5848 MIPS 2.8565 relative

Benchmarking: biz.q r0, label (when not taken)
	took:   2603414498 nanoseconds 307.2888 MIPS 2.5060 relative

Benchmarking: bsr/rts (round trip)
	took:   4164010331 nanoseconds 192.1225 MIPS 4.0083 relative

Benchmarking: bsr/rts (round trip, stack misaligned)
	took:   4047076063 nanoseconds 197.6736 MIPS 3.8957 relative

Benchmarking: bsr.b/rts (round trip, short negative displacement)
	took:   3927501483 nanoseconds 203.6918 MIPS 3.7806 relative

Benchmarking: bsr.b/rts (round trip, short negative displacement, stack misaligned)
	took:   4129881186 nanoseconds 193.7102 MIPS 3.9754 relative

Benchmarking: hcf #0, #0 (no op vector)
	took:   4003440809 nanoseconds 199.8281 MIPS 3.8537 relative

Benchmarking: link r5, #-64/unlk r5 (round trip)
	took:   4623583909 nanoseconds 173.0260 MIPS 4.4507 relative

Last edited by Karlos on 19-Oct-2022 at 10:25 AM.

_________________
Doing stupid things for fun...