@ppcamiga1

You have missed the point by a margin so wide I am somewhat lost for words.

1. Compatibility with what? It's a virtual machine running on a host. It's not an emulator or a simulator. It's a bytecode interpreter. The bytecode exists to support an assembler that adopts a 68000 style syntax.

2. Having fun is a reason. Nostalgia is a reason. Making changes to the original 68000 to satisfy your own curiosity is a reason. Doing it because you can is a reason.

3. It's not an Amiga and doesn't claim to be one. It's not even a computer. It is a hosted interpreter with the host providing some basic IO, graphics, audio etc. You write some 68000-style assembly for it, compile it to a bytecode binary, run that in the interpreter and hope it works.

4. Changing to little endian changes nothing. See 1. and 3. And let's be honest, what has "big endian" ever done for you, anyway? Nothing. You have to live the cognitive dissonance of everything working one way in a register but the other way around when instead of a register you have an equivalently wide unit of memory at some address. At least little endian is completely consistent in this regard.

5. It isn't binary compatible. It doesn't try to be binary compatible. It is mostly assembly language compatible except for the differences already noted. As an aside, it's way more syntactically compatible than PowerPC which doesn't even formally enumerate bit positions the same way around as 68000.

6. There is a Amiga style window manager already if that's what you want.

Last edited by Karlos on 23-Mar-2022 at 06:57 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

6. There is a Amiga style window manager already if that's what you want.

This has come up before. Amiga graphics on Unix/Linux is not just a window manager, it's Intuition, e.g. AxRuntime.

Last edited by bison on 24-Mar-2022 at 02:59 PM.

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

@bison

I was actually referring to the various AmigaOS themes for Linux window managers. AxRuntime is more like AmiWinX, but with a role reversal.

_________________
Doing stupid things for fun...

@Karlos

Quote:

The real GPR names are r0 - r15. The names d0 - d7 explicitly alias r0 - r7 and the names a0 - a7 explicitly alias r8 - r15. The name sp is an explicit alias for r15.

So I did understand it as intended.

Quote:

As for the stack pointer, I've always used a dedicated register for that in other virtual machine designs (even going so far to have different call stacks, register save stacks and parameter stacks). The reason I didn't do that here is because of the effective addressing model. In 68000 you can use all the same addressing modes on a7 as you can any other register. Supporting that in conjunction with a 17th register would have messed up the internals. And in any case, by making the registers truly general purpose, the loss of one of them to be "the stack" isn't so bad as there is reduced pressure on the remainder. Invariably, in my experience, imperative code tends to only need a handful of address pointers at any moment and has a greater need for available integer registers.

That makes practical sense. The reasons you cite is likely the reasons why the 68000 was designed that way. Prior to learning the 68K my only CPU experience was the 6502 ISA. While programming my Commodore in the 80's. IIRC the 6502 stack couldn't be accessed directly but through instructions. But it did have a known layout. After this the dual SP/A7 naming scheme looked quirky.

Quote:

ABI wise, I go for passing the first integer parameters in r0, r1, ... and the first pointer parameters in r8, r9... and the first floating point parameters in fp0, fp1, ...

That makes sense, like 68K, even if your 64K isn't limited in the same way.

Quote:

Integer return is usually in r0, pointer return in r8 and floating point return in fp0. This makes the ABI somewhat familiar to people using the 68000 aliases.

It would yes.

Quote:

As an aside, many of the host functions return two values, for example r0, r1 (if r0 contains a value, r1 can contain an error/success code) or r8, r0 (if r8 contains a possibly null address, r0 can contain the error/success code).

Multiple return values are useful and you can feel it when it would be useful but not supported in an API.

Quote:

The destination register number in the lower nybble, the source register number in the upper nybble. For example, the operation "add.q r5, r7" would have an encoding of 3 bytes:

Makes sense.

I think endian order can be funny sometimes. Even though little endian became defacto standard the byte bit order standardised on across the board is big endian. For example msb to lsb.

Quote:

The documentation is mostly up to date. Certainly there haven't been any radical departures from the layout described here.

IMHO it was quite comprehensive and looks like quite a bit of work went into it.

@Karlos

AmiWinX? You mean AmiWin, the X11 server?

As for Amiga themes for various *ix desktop environments… as pointed out already, the theming and looks isn’t what makes it Amiga, AxRuntime seem more like Wine, really. AxRuntime and ARIX seem to overlap a bit.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Yeah. It was possible to compile a number of simple Unix applications that needed ixemul and used X to run on AmiWin (could've sworn it was AmiWinX, lol). I remember porting a few simple ones myself.

Conceptually, AxRuntime seems like this in reverse to me. Building Amigoid source applications and running them on Linux. I appreciate it's not a perfect analogy.

Last edited by Karlos on 14-Apr-2022 at 09:27 PM.

_________________
Doing stupid things for fun...

@Karlos

Mm, making X11 clients (and they don’t have to be unix, X11 was “native” to many operating systems) on Amiga isn’t so hard by itself, as X11 is first and foremost a (network) protocol :)

Again, for me, AxRuntime seems more like Wine, but with recompile necessary due to endianess etc. and not a protocol. But maybe this is semantics in a larger picture, where X11 is viewed as a “GUI” and people think the client is the server and vice versa.

(And then there is Oberon, Rebol and a few others with their own GUIs… hm, been a while)

Last edited by kolla on 14-Apr-2022 at 10:43 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Well done with this design. It looks like great fun and I wish I had time to join in.

Thank you for dropping the absurd "big-endian" restriction we seem to have inherited from Motorola. I was brought up with PDP-11s in the 1970s and little-endian was the only game in town.

Big-endian is counter-intuitive, its only advantage is that it simplifies the design of an ALU: you know where the sign bit is, regardless of the word length. I can't think of any other use for it.

I also like the general-purpose nature of the stack pointer: again, like the old PDP-11s. In a PDP-11, you could perform any operation on any register. So, if you wanted to (and I can't imagine why you would want to) you could add the content of an indexed memory address to the PC, stepping forward or backward by some variable amount. That ability did lead to some interesting bugs!

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

Just to be clear, I don't have anything specific against big endianness. The main reason I chose little endian for this design was for simplicity given the fact the target host is little endian. It really doesn't make anything like as much difference (even when writing assembler) that people first think. An assembler dc.l $abadcafe is written same whether you are big or little. The only difference is when you want to access different sized elements at the same location. Here little endian is consistent with the register behaviour, whereas on big endian memory models, you have to offset the address to get less significant component parts.

There are other much bigger differences than the endianness. The whole conditional branching model is off the chart different than 68000, again for simplicity.

Quote:

So, if you wanted to (and I can't imagine why you would want to) you could add the content of an indexed memory address to the PC, stepping forward or backward by some variable amount

You can create jump tables in the instruction stream that directly model a switch case using tricks like that. The caveat is that each case handler has to align to a consistent size. Years ago I had z80 emulation for 68K that worked a bit like this. The handler for each instruction occured on an aligned 32 byte boundary, giving 32 bytes for the actual handler plus the the logic to decode the next operation and directly jump to the next handler. Obviously some instructions were had too much logic so their handler was simply a branch to some longer code to complete it.

So, with the next z80 opcode byte in d0 and the first handler in a0, you'd do lsl.w #5, d0 then jmp (d0.w, a0) to branch immediately to the handler. That's tantamount to just adding a memory derived offset to the PC as you describe. Each handler ended with this same pair of instructions. This eliminates the need for an explicit fetch/execute loop and I was able to golf most handlers to fit in the scheme without having to branch out.

Last edited by Karlos on 15-Apr-2022 at 10:33 AM.

_________________
Doing stupid things for fun...

@Hypex

Quote:

So I did understand it as intended

Yes.

Quote:

I think endian order can be funny sometimes

And how. For example, much has been made over the years of PPCs big endianness as an advantage, and yet when it comes to bitwise operations, it enumerates those in the opposite sense to 68K. What 68K considers bit zero, PPC considers bit 31.

Quote:

IMHO it was quite comprehensive and looks like quite a bit of work went into it

By far the longest slog was the assembler itself. I had a reasonable notion of how the interpreter should or at least could work but I forced myself to get a minimally viable assembler generating bytecode files before beginning on the interpreter. Knowing the fun stuff was still to come, this served as an incentive to get it finished However, doing it this way also allowed the interpreter to be tested against bytecode as it was being built, reducing errors. There were only a small number of minor revisions to the bytecode so I guess that validates the approach of doing the fun stuff last.

_________________
Doing stupid things for fun...

I recently decided the basic emulated framebuffer, while functional was a bit boring, especially in 8 bit. It has been upgraded to support a virtual framebuffer larger than the visible display (somewhat akin to a superbitmap), with control over the viewport offset. This is also possible even when the bitmap is the same size as the viewport, out of bounds X and Y portions wrap independently.

To make this more fun to play with, there's an optional "script" processor inspired by the Copper. We've called it the Finite Interpreted Line Transfer Handler, or FILTH*. Like the Copper, this has a simple interpreter that on a given "beam coordinate" (i.e. viewport coordinate) can execute commands. You can set, swap or modify palette entries, viewport offset values, etc and have as many of these instructions as you want at any given pixel position. This adds a small amount of overhead to the display update (1ms for a 320*240). Best, or worst, of all depending on your viewpoint, it can also modify itself, e.g. it can set or modify values within an unsigned 16 bit distance of the base address of the script. This means it's possible to animate various effects without any mc64k instructions being used at all.

*Any other meaning similarity outside of Amiga custom chip circles is entirely coincidental

Last edited by Karlos on 15-Apr-2022 at 05:28 PM.

_________________
Doing stupid things for fun...

Footage or it never happened....



Getting FILTHy

_________________
Doing stupid things for fun...

@tonyw

Quote:

Thank you for dropping the absurd "big-endian" restriction we seem to have inherited from Motorola. I was brought up with PDP-11s in the 1970s and little-endian was the only game in town.

I thought it was inherited from AmigaOS which wasn't designed to be portable. But what's absurd about it? The only problem I see is that little endian is more popular because it's become the defacto standard.

I grew up with a 6502 ISA in the 8501 of my C16 which is little endian but only went as far as pointers since data was 8 bits. Still it was in low byte, high byte order. But wasn't the PDP-11 a hybrid endian? When I looked it up the 32 bit long words had short words in big endian order with each byte in lttle endian order which sounds confusing.

Quote:

Big-endian is counter-intuitive, its only advantage is that it simplifies the design of an ALU: you know where the sign bit is, regardless of the word length. I can't think of any other use for it.

That's the main one, but there are others. You can look up 4 character IDs directly in code. It's obvious WYSIWYG so easier to interpret binary data. And you can read and write a data stream with any size and it will end up exactly as it looks.

With little endian people do reversing hacks in C code to check for IDs. But I think that's more to do with lazy coding as portable code can be written that works on any endian. And yet I still read online about people in classes that think endianess is irrelevant. Opposite to big sign it can test data size in little. But it can't read and write data streams in any size as the words would all be reversed so little endian CPUs with different word sizes cannot share multi word data. Only one size must be used even if the CPU can access a larger quantity.

But what I find interesting is that the bit order in little endian is in big endian order. Even in the 6502, with BCD, the nibbles are coded in big endian order. Technically not a byte which is probably why.

@Karlos

Quote:

And how. For example, much has been made over the years of PPCs big endianness as an advantage, and yet when it comes to bitwise operations, it enumerates those in the opposite sense to 68K. What 68K considers bit zero, PPC considers bit 31.

I mean like I replied above. The bit order in little endian is in big endian order. I suppose they had to be standardised. Before different endians came into play. Since there were bits before bytes. Which came first, the bit or the byte?

But yeah, I never got that PPC bit reversing. They've almost done the oppose to little endian which has bits in big endian order. Just like 68K. And the 6502. Was it because of IBM? Since Motorola pretty much dropped the 68K and 88K in favour of PPC.

I suppose bit 0 is the first bit in the word on the left. But it's normal to number them in reverse order. And that's how we also think when doing masks and bit testing in C. The greater size at the top. At the end of the day. WTH?

Speaking of masks, I wondered about that PPC rotate with the optional bit mask. Sure it's useful with limited circumstances being able to select a bit range. But I thought most code would need to read a mask out of a variable, and not all masks are a bit range, so seemed redundant in most cases.

Quote:

By far the longest slog was the assembler itself. I had a reasonable notion of how the interpreter should or at least could work but I forced myself to get a minimally viable assembler generating bytecode files before beginning on the interpreter. Knowing the fun stuff was still to come, this served as an incentive to get it finished However, doing it this way also allowed the interpreter to be tested against bytecode as it was being built, reducing errors. There were only a small number of minor revisions to the bytecode so I guess that validates the approach of doing the fun stuff last.

I can imagine that is the bulk of the work. I find documenting changes can be easy to lose track on. Sometimes I don't do it when updating code and then need to diff my code to see what changes I made. A recent unfinished project had me going through the entire source as I was updating my documentation for it. I numbered out the features and changes I added and there were a lot. By the end of describing it all it was almost as big as the source which became a monster.

With another idea I actually documented it first. Now I have to write it. Which is funny as it's inspired by another Amiga project idea I had that I'd barely started. I ripped off my own idea for somethng else! Before the original idea was even working.

Last edited by Hypex on 17-Apr-2022 at 06:31 PM.

@Hypex

I think that the trajectory CPU evolution has shown that whatever inherent benefits big endian may have are not significant enough to matter in the grand scheme of things. Personally, yes, I prefer the notation. However, I rarely have to worry about endianness even when writing low level code. I did think about making mc64k big endian by swapping every move operation between memory and registers on little endian hosts. Weighing up the differences it would make to the assembler versus the additional overhead, it just didn't seem a worthwhile trade off at all. Complexity for complexity's sake.

_________________
Doing stupid things for fun...

@Karlos

I'm not a hardware engineer by any means. But it seems to me that little endian became dominate because of archaic reasons. For example, early CPUs like 8 bit ones, were expanded in design by adding another byte. But when it comes to 32 bit and 64 bit sizes it's more than a byte added and the CPU wants to read that whole quantity into the register. To me it looks like that would need extra logic as the CPU needs to read the data in reverse order. Then again it might process it internally in byte quantities regardless. Suppose I should ask a chip designer.

However, in later years and a long time ago now, Intel CPUs feature native BE instructions. I don't mean BSWAP but ones like MOVEBE. So all the complaining about big endian data in network structures is now moot. Intel can read/write it natively, since years, who cares anymore? If they are still struggling with it then C/C++/All language compilers need a serious update. Or programmers need to learn how to write write basic portable code. I laugh when I read people online say big endian is wrong; and only bacause litle endian is popular. Ten years ago MIPS BE would be in routers, Then MIPS LE. Now ARM LE is getting common I take it.

I think this is like a VHS vs. Beta. I don't think LE won because it was technically better. But because it flooded on the market. Intel tends to be blamed for LE being dominate thought IBM did make the first move. But Intel didn't choose it. It was in the ISA they were asked to produce as a MPU by Datapoint. Along with TI. And in the end neither Intel or TI produced an acceptable working CPU for Datapoint. But Intel got to keep the design and rest is history! Not the best ISA I thought but TI could have ended up as the number CPU brand of all time instead!

@Hypex

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.

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.

Last edited by Karlos on 17-Apr-2022 at 08:47 PM.

_________________
Doing stupid things for fun...

I'm gradually moving away from the actual 64K core interpreter for the time being to work on imaginary graphics and audio to go with it, again generally following the idea of "what it...?"

_________________
Doing stupid things for fun...

@Karlos

big-endian cpu is one and only still important thing from original hardware.
only computer with big-endian cpu may be source and binary compatible with old Amiga software.

MC64K as not compatible and not modern is to be honest not worth use.

@ppcamiga1

You pretty obviously haven't got a clue what this project is, what it is not, what it is for or who it's aimed at. I refer you to my last reply where you basically said exactly the same thing previously

_________________
Doing stupid things for fun...