@thread

Virtual Motorola 68000 "m68k" Machine With Up To 3.2GB RAM Expected For Linux 5.19

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

@bison

Now that is cool.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Instructions such as MOVEBE means you have to do load/store for everything though, rather than being able to take advantage of the CISC nature of the architecture. In practise this still means more instructions and more pressure on available registers to operate in big endian than the same operations in little. And to leverage this at all, you're probably going to have to resort to assembler as there's no easy way to express that you are doing endian conversion in idiomatic C. Clever compilers can see a sequence of shifts and rotates and recognise that it's a bswap and some may even detect the usecase movebe. But, more likely, you'll end up either using compiler builtins, inline assembler or just assembler sources in conjunction with the your C code.

Compiler built ins are useful though not exactly portable. However I don't see a problem with MOVEBE being a RISC like load/store only, since it's for a specific operation and not supporting all addressing modes. If you look at BSWAP it has to operate in a register. So it would need reading into a register and then BSWAP called. MOVEBE combines this into one instruction. In any case, if any real work is done, it will be in registers.

It's better than what PPC has with reverse loads, even though it works the same, because compiler built ins aren't optimised for registers. They are designed to operate on a variable. Which is also silly since you need to read or write to memory. But the GCC macros I checked out only took a value and not an address. Therefore, on x86 this will become a read, then a BSWAP. On PPC, this will become a total mess, with all this code swapping bytes. It's somewhat irrelevant that 68K, which had no codes to do it, can do it in three with a roll, swap, roll. But on PPC, the asm of the built in will load into a register and then need to manually swap it all around. This is ridiculous really because one instruction would read it directly in reverse order. The macro really isn't optimsed for PPC so it comes off as looking crap when it can do better. Perhaps assembly is the only way.

Quote:

I agree that there's no universal rightness or wrongness to the endian debate. In my view, big endian is much more natural based on how humans understand numbers of different magnitudes. Nevertheless, that human intuition applied to silicon circuitry is perhaps "carbon privilege". In the end, it's all just encoding. I've no doubt that machines natively big or little by heritage have optimised their access and usage of data in each encoding to equal degrees.

The benefits are likely humanised. I mean, when reading a hex dump, it's a lot easier to decipher. A little while back I was doing some software reverse engineering and mapping out data in a hex dump so I could create a C struct compatible to it. Had it been in LE order it would have done my head in. This also explains why I was confused by BMP file because the words were backwards! I had forgotton about my 6502-ish upbringing with lo byte, hi byte.

However, there are other examples of right to left order, such as the Hebrew language. More common in times past. So humans don't always work in the same forward order.

@Hypex

Your problem with little endian dump interpretation is why I use GHex for it rather than eyeballing text.

Quote:

However, there are other examples of right to left order, such as the Hebrew language. More common in times past. So humans don't always work in the same forward order

Curious point. Are Arabic numbers little endian in the context of Arabic writing? They are written with the most significant digit on the left but the language is also read right to left, meaning the least significant digit should be encountered first.

Last edited by Karlos on 27-Apr-2022 at 08:48 PM.

_________________
Doing stupid things for fun...

New video up...

This doesn't really demo anything about the CPU, it's all about the "homage to COPPER" display controller

FILTHy Parallax

No virtual CPU cycles are used to create the effect.

_________________
Doing stupid things for fun...

@Karlos

That video deserves an Oscar!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Someone already made that quip, lol.

_________________
Doing stupid things for fun...

What next? A version of geos converted X64?

@hardwaretech: next is an Amiga chipset with packed graphics instead of bitplanes.

@hardwaretech

EmuTOS.

Maybe I'll write a z80 emulator for it.

_________________
Doing stupid things for fun...

@cdimauro

You may joke, but why not? The beauty of a virtual machine is you can do whatever you can write software for.

_________________
Doing stupid things for fun...

@Karlos

Nice work.

@racer_hex

Love a bit of beam racing, even if the beam is fake lol...

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro You may joke, but why not? The beauty of a virtual machine is you can do whatever you can write software for.

No joke: I was somehow serious.

However it'll be a huge change on your VM, which requires a lot of work.

@cdimauro

On the contrary, I don't think it would take much. The host has plenty of space to provide all kinds of fake hardware to the VM core. I'd just use something similar to the code in the gist and provide the same sort of interface I have now to the VM and the corresponding display controller logic to unpack the visible pixels to the format the native host display is using.

_________________
Doing stupid things for fun...

@Karlos: but implementing the Amiga chipset (in packed format) will require some time for sure.

@cdimauro

Well, that's different. I was just going for a straight implementation not based on anything specific.

_________________
Doing stupid things for fun...

@Karlos: so, not an Amiga chipset, but something different. Then it'll take much less.

@cdimauro

Yes, in the same way the VM is not an actual 680x0 implementation.

_________________
Doing stupid things for fun...