@cdimauro

Wow, that was a long reply, sorry, I've overseen question addressed to me.

Quote:

@michalsc Quote: michalsc wrote: All I wrote is valid for aarch32. Soon I will test how it changes on aarch64. But, even if it changed there, there is no need to worry about endianess of amiga-like systems beyond 32-bit... Is there any reason why you started using AArch32 instead of directly go to AArch64? With the latter, and its 31 registers, you can map all 68K registers to a (fixed) subset of available registers, and still have plenty of free registers to be used for temporary data & calculations.

Yes, I was thinking about doing the emulation for aarch64 only and one of the reasons was indeed doubled number of free registers. But then I have realised that I want this m68k JIT to be used not as a universal engine for any needs but rather as virtual m68k environment seamlessly integrated with 32bit AROS. Environment using the same structures and the same system internals and, hopefully, enabling running old m68k software on AROS running on ARM cpu in big endian mode.

Having done that with aarch64 would mean that I need something similar to x32 ABI on linux - OS running on CPU in 64 bit mode, but using 32 bit pointers. But, since x32 was not a big success on intel and the attempts to provide something similar to ARM are in very early stage I would have to put significantly more effort (and time) to realise it for AROS.

So, I reviewed my opinion and went for aarch32.

PS. Regarding big endian being optional feature on AROS. It has been already checked that even armv8-a RK3399 (the cpu of RockPro64) supports endian switching in 32bit mode. So, the feature seems to be not as optional as one could think (yes, it's hardly existing on embedded CPUs such as stm32 series, though).

@hth313 Quote:

hth313 wrote: @cdimauro I think AROS is a lot more interesting than AmigaOS in this aspect. As you say, AROS is not tied to the Amiga hardware in the same way and offers more flexibility. You also avoid the ownership issues we have be seeing way too much of.

That's something which I forgot to mention: thanks for recalling it.

Yes, AROS has no owners, can be freely adapted to specific personal needs, and what's more interesting is that it's very commercial-friendly, since it has no viral licenses like GPLs (the license is viral ONLY for the code the it's changed, which is required to be given back to the community. But the viral side does NOT extends to other code, like GPLs do instead).
Quote:

If you change 68k a lot, it is not really 68k anymore.

I agree. But as an assembly coder, if most of the ISA looks and works the same, I can quickly adapt.
Quote:

Source compatibility helps reusing low level stuff like math libraries and arch specific OS code, but little else. Most people do not care so much about it as they are not writing in assembly language anyway.

True. At the very end it's not common anymore writing assembly code even in the embedded market, but can happen if needed (see below). That's why source-level compatibility can be enough.
Quote:

I think binary compatibility is important. Some minor changes can be made with unusual instructions and there can later be a path to 64-bit which breaks compatibility when used. If you make a new encoding, you end up with a new Coldfire, something that looks similar but isn't. Motorola did this with the 6811 to 6812. It helped reuse of some existing assembly code, but otherwise they are very different from a tooling perspective. 6812 was quite successful I believe and eventually killed the 6811 (but that was more likely due to decision on the Motorola side than anything else). It was more like an evolutionary transition in a given segment. They may look a bit similar but they are really quite different.

That's also what happened to the 8086, which was almost fully 8085-compatible at the source level, and this helped A LOT the transition/porting of 8085 code to the (completely) new 16-bit ISA.

I understand what you say, and I fully agree that the tooling is very different once you lose binary-compatibility. However if the new ISA is 100% (or very close) source-level compatible with the old one, changing the tools might become quite easy.
I'm talking about assemblers & compilers which directly emit the binary code, which are the most important and critical ones when we talk about tooling. If the ISA is very similar and with the possibility to directly map one instruction of the old ISA to another one of the new ISA, then the effort to introduce the support to the new ISA is really reduced. I wouldn't say trivial, but not a big burden.
A disassembler (which is the other important tool) needs to be rewritten, but many parts of the old one can be recycled, and if the new instruction encoding is simpler, then it might require only a little work.

Those are also the reasons why, at the end, I decided to keep 100% x86/x64 source-level compatibility with my NEx64T ISA: to quickly get support by just (not only, but mostly) changing all emit instructions generating the corresponding new one. The disassembler is very different, but instruction decoding is a piece of cake and has absolutely not the burden of x86/x64 (I would say that it's really trivial, and comparable to ARM/Thumb-2, RISC-V/Compressed ISA).

Anyway, the more important question here is to decide if it makes sense to just revival the 68K as is, keeping all of its defects, or thinking about giving it a modern rewriting/redesign.

100% source-level compatibility is a good option IMO, which opens also the doors to transparent 64-bit introduction (with the SIZE field which finally uses the 0b11 encoding for it).
Quote:

Having said that, I do not really mind going the source level compatibility path if there can be significant improvements or other motivations (64-bit as you mention), but I think there are also significant risks with it. Maybe it is not worth fixing what is not broken?

IMO it's not worth fixing the current 68K design: decoding instructions is complicated, and introducing a 64-bit mode would further complicate the things.

An ISA redesign will have the advantage to get a mich simpler decoder, with evident benefits: much less transistors to implement it, less energy consumed, and maybe less pipeline stages (which also means better performances). So, it will be even more competitive.


@pavlor Quote:

pavlor wrote: Quote: cdimauro wrote: BTW, a backport of some (or all) AmigaOS4 features to the Amiga o.s. (68K) is not possible, due to the ownership of part of the AmigaOS4 by different third-parties, the lack of interest on this operation, and the lack of money to back it. I don´t think this is such a major issue.

Really? With the new code which is not even owned by Hyperion? I don't think that you can easily convince the real owners to port back their code to 68K. My personal opinion, but I've found absolutely no interest from some of them, since I joined back the Amiga community.
Quote:

Major problems would be performance and memory requirements of said OS components. You can´t market OS requiring 16+ MB RAM for A500 users.

AROS requires much less resources, and it's even not optimized for 68K.

Anyway, I was primarily talking about the improvements on exec, graphics, intuition, dos, etc. IMO they should requires only a bit more memory.
Quote:

Quote: I think that the 68K can have some chances to go back to the embedded market Glad I´m not the only one with rose-tinted glasses.

Since when you started working on the embedded market, and you know the needs which are here?

I've already working and still working on some project in this market. I've used a crappy 8-bit AVR from Atmel. Recently I'm switching to a new (much better) ARM platform from Microchip. And I'm also in contact with STMicroelectronics for a future ARM platform, giving hints about the current needs of the market which I (and not only me, of course: there's A LOT of competition) work on, and what would be better to have, in order to have a better (and cheaper) product, and allowing STM to be more competitive in this market.

BTW, with a 68K or (better) source-level compatible ISA I can easily think about rewriting part of my code in assembly. Because it's quite trivial working with this splendid ISA, and in the embedded market sometime you're short in resources (FLASH space especially). With a 68K I can do it. With an ARM, I prefer to avoid it as much as possible since it's not that easy, I will do it only if the alternative is pointing a gun to my head.

So, can you share similar experience / (real, concrete) work, or your rose-tinted glasses are just the usual ones which you vest?

@cdimauro

Once you return 68k to the market, we may talk. Until then, empty words, nothing more...

@matthey

Quote:

Actually, the embedded market is much bigger than the desktop market. There are several times more chips with ARM cores sold each year than there are people on the planet earth. The profit margins for the embedded market are often lower than the desktop market but the volumes have resulted in very cheap hardware.

Sure I intended consumer market because Amiga, until now, is always related to this part.

Quote:

ARM is a good choice for cheap hardware and the embedded market. However, it may not be the best choice for the Amiga. We need to look at what we have on our side of the fence before we jump the fence to what looks like greener pastures. The AmigaOS 68k is more optimized for the 68k and big endian. The 68k AmigaOS has a tiny footprint exceeding most computers today. The 68k Amiga has the largest Amiga user base and software due to compatibility. Amiga developers are more experienced with the 68k. +====+=====+====+ AArch64 is the most popular and standard ARM ISA but can have 50% larger code than the 68k. A 68k JIT emulator and run in UAE will use more memory. ARM requires dividing the Amiga user base and development again (stop supporting the PPC & 68k?).

I agree with you, the difference between us is due my extreme pragmatism. I'm italian but sometimes I like american's ways to do jobs. We don't have a modern 68k platform to develop, yours are all theories and good intentions nothing more.
Even if you could get a modern 68k reborn and upgraded cpu you will be always slower than arm due process fab, caches sizes, industry support.
I repeat your is a very nice dream and will continue to be a dream until some big boss like IBM, NXP, ST Micro, and others will remember there was once upon a time something called MC68k with high efficienty and easy to program..
Instead today we have a lot of low priced arm boards to fun and experiment with, stayng in embedded market. The needed steps are: first an AmigaOS port and than some specific simply "killer apps", where new toy is overall better than others.

..Try to use your low code density and your efficienty mantra, applied to your ideas and you'll agree me too.

Last edited by Fl@sh on 10-Mar-2019 at 10:17 PM.
Last edited by Fl@sh on 10-Mar-2019 at 04:46 PM.
Last edited by Fl@sh on 10-Mar-2019 at 04:44 PM.
Last edited by Fl@sh on 10-Mar-2019 at 10:59 AM.
Last edited by Fl@sh on 10-Mar-2019 at 10:58 AM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@cdimauro
Source level compatibility isn't worth much. Most current code is written to be portable and in higher level languages.

The only use case of 68k source level compatibility would be the company that suddenly want to scale their low performance code to something much higher performing while not having enough market to warrant a full rewrite. It'd be a better idea to learn dentistry for a certain type of fowls...

@michalsc Quote:

michalsc wrote: @cdimauro Wow, that was a long reply, sorry, I've overseen question addressed to me.

Sorry. On other forums I'm used to do multiquote.
Quote:

Quote: @michalsc Quote: michalsc wrote: All I wrote is valid for aarch32. Soon I will test how it changes on aarch64. But, even if it changed there, there is no need to worry about endianess of amiga-like systems beyond 32-bit... Is there any reason why you started using AArch32 instead of directly go to AArch64? With the latter, and its 31 registers, you can map all 68K registers to a (fixed) subset of available registers, and still have plenty of free registers to be used for temporary data & calculations. Yes, I was thinking about doing the emulation for aarch64 only and one of the reasons was indeed doubled number of free registers. But then I have realised that I want this m68k JIT to be used not as a universal engine for any needs but rather as virtual m68k environment seamlessly integrated with 32bit AROS. Environment using the same structures and the same system internals and, hopefully, enabling running old m68k software on AROS running on ARM cpu in big endian mode. Having done that with aarch64 would mean that I need something similar to x32 ABI on linux - OS running on CPU in 64 bit mode, but using 32 bit pointers. But, since x32 was not a big success on intel and the attempts to provide something similar to ARM are in very early stage I would have to put significantly more effort (and time) to realise it for AROS. So, I reviewed my opinion and went for aarch32.

Understood, and I agree with your current choices.

Any possibility to push AROS towards AArch64? AROS is targeting "desktop" market, and on desktop 64-bit are the norm from some years now. BTW, only the first RPi supports 32-bit: all others support AArch64.

32-bit only make sense on the embedded market, which currently AROS is not interested to cover.
Quote:

PS. Regarding big endian being optional feature on AROS. It has been already checked that even armv8-a RK3399 (the cpu of RockPro64) supports endian switching in 32bit mode. So, the feature seems to be not as optional as one could think (yes, it's hardly existing on embedded CPUs such as stm32 series, though).

Which is ok and a rational choice.


@pavlor Quote:

pavlor wrote: @cdimauro Once you return 68k to the market, we may talk. Until then, empty words, nothing more...

You're changing argument now (which doesn't surprise me).

Maybe it's not clear to you, but we were talking about the POSSIBILITY to embrace (again) the embedded market for the 68K (or a redesign). So, just discussing about it.


@megol Quote:

megol wrote: @cdimauro Source level compatibility isn't worth much. Most current code is written to be portable and in higher level languages. The only use case of 68k source level compatibility would be the company that suddenly want to scale their low performance code to something much higher performing while not having enough market to warrant a full rewrite. It'd be a better idea to learn dentistry for a certain type of fowls...

Well, the thing is that 68K can count on many passionate assembly coders, which can appreciate the possibility to continue to code exactly the same way on a new ISA which retains 68K source-level compatibility.

I think that this possibility shouldn't be underestimated. As already discussed, it was a winning point for Motorola with its 6812 (source-compatible with 6811), and for Intel with its 8086 (source-compatible with 8085).

The 68K ISA needs to be extended to 64-bit, so binary-compatibility will be lost anyway, and tooling require rewritings/support.

Better to take the chance and redesign the opcodes to make them much easier to decode, with the benefits which I've already reported.

@cdimauro

Quote:

Any possibility to push AROS towards AArch64? AROS is targeting "desktop" market, and on desktop 64-bit are the norm from some years now. BTW, only the first RPi supports 32-bit: all others support AArch64.

Yes sure, AROS has been already successfully tested in 64 bit (on x86_64) and I think moving to aarch64 will be natural choice soon. But let me first finish 32bit big endian version for RasPi. Once this is done I will start working either on different boards (I have RockPro64) or on aarch64 (for RasPi and for RockPro64), or both :)

@cdimauro 

Quote:

With the new code which is not even owned by Hyperion? I don't think that you can easily convince the real owners to port back their code to 68K. My personal opinion, but I've found absolutely no interest from some of them, since I joined back the Amiga community.

Even a lack of interest beyond OS 4.1 FE to 4.2 or 5? Maybe another company besides Hyperion would be interested. Although, since there is no CPU being manufactured for 68k anymore, that surely contributes to the lack of interest. The number of Vampire sells (if significant enough) may change some minds, too.

@michalsc

Quote:

Yes sure, AROS has been already successfully tested in 64 bit (on x86_64) and I think moving to aarch64 will be natural choice soon. But let me first finish 32bit big endian version for RasPi. Once this is done I will start working either on different boards (I have RockPro64) or on aarch64 (for RasPi and for RockPro64), or both :)

Yes, please finish the RPi port of Aros first. I'm anxiously awaiting its completion.

@michalsc Quote:

michalsc wrote: @cdimauro Quote: Any possibility to push AROS towards AArch64? AROS is targeting "desktop" market, and on desktop 64-bit are the norm from some years now. BTW, only the first RPi supports 32-bit: all others support AArch64. Yes sure, AROS has been already successfully tested in 64 bit (on x86_64) and I think moving to aarch64 will be natural choice soon. But let me first finish 32bit big endian version for RasPi. Once this is done I will start working either on different boards (I have RockPro64) or on aarch64 (for RasPi and for RockPro64), or both :)

Have fun with your nice project: it's really interesting and absolutely promising.


@davidf215 Quote:

davidf215 wrote: Even a lack of interest beyond OS 4.1 FE to 4.2 or 5?

We were talking about backporting some OS4 code to 68K.

Anyway, some part of the post-Commodore community is obviously interested on OS4.2 (and even a improbable OS5).
Quote:

Maybe another company besides Hyperion would be interested.

The problem is that, as I said before, Hyperion has no ownership on the whole OS4 code. This will not change with another company.
Quote:

Although, since there is no CPU being manufactured for 68k anymore, that surely contributes to the lack of interest.

Indeed. But, as I said before, another problem is that 68K has only 32-bit support, whereas a 64-bit extension/rewrite could make it more attractive.
Quote:

The number of Vampire sells (if significant enough) may change some minds, too.

Could be. Vampire is a nice project which has revamped (!) interest on 68K.

Unfortunately I think that this 68K ISA extension leaves a lot to desire, and gives problem for the scalability of the platform. But that's my personal opinion.

How compact is compiled RISC-V code?
RISC-V (32-bit, compact extension) code density < ARM Thumb-2

There's still some hope...

@cdimauro

RISC-V has no big-endian mode unlike ARM7.

@Samurai_Crow: it's optional. The ISA is little-endian, but vendors might decide to support big-endian (AFAIR keeping little-endian for opcodes, like ARM).

However the good thing for alternative ISAs is that RISC-V code density isn't better than current solutions. So, there's might be room for competition, at least in the embedded market (which the biggest one).

@cdimauro

Ok. Cool.

So the only real priority should be getting a decent Amiga-like OS running bug-free?

@cdimauro

Quote:

cdimauro wrote: How compact is compiled RISC-V code? RISC-V (32-bit, compact extension) code density < ARM Thumb-2 There's still some hope...

That was not my feeling. Actually, it did not say much as all. There are noise due to library code that need to be taken out, which is a problem when using LTO, otherwise you can just look at the compiler output instead of the linker output.

The conclusion is that there isn't all that much variation, some extremes which would help pointing to things that can be improved. Basically, if something sticks out, there is usually a reason for it and it can be fixed. Most of the variation seen is in differences in the tooling, not really so much in the ISA.

Having worked with these matters I can only say that they are to some degree wasting their time. You can find things to improve, but most changes are from improvements in the tools and often also in adjustments to how the actual application code is written. If you want to make things better, just have someone that understands the compiler study the output and suggest how to tune your code, you will most likely gain the most from that. If that someone also can make some adjustments to the compiler, you will probably improve things further.

If you pay someone for telling how different ISAs compare, then you are really wasting your money. They are essentially similar, as long as you do not make too extreme compares (such as comparing an 8-bitter with a 32-bit ISA, and especially if the application code is written for a 32-bit ISA in mind).

Yes, the people paying him for this are so totally wasting their money. The only thing of value they can gain of this is how much worse gcc is for their non-mainstream target compared to a well maintained mainstream one (ARM). It did seem to do reasonable well actually.

Yes, I know this might go a bit against what you might think, but ISA differences are really not all that important and tend to drown in everything else. Besides, it depends a lot on your application code. I do not doubt that one can show this is better than that, like you can do with most things you want to show, but in reality it does not mean much.

Having said that, please bring a new 68k on, or RISC-V, I like both. You can probably also convince people either is better, but as I said, in reality your mileage will vary.

Thanks for the link anyway, it gave me a couple of things that were helpful, actually it reinforced my belief on a couple of things that I already knew. Always good to have your wishes confirmed, right?

@hth313: understood, but then, if ISA doesn't matter... why there are still products which are different from mainstream ISAs, trying to gain some market?

Isn't code density still important? I think so, because ISA vendors are putting A LOT of effort on getting a good code density, either by adding specific instructions/extensions to the ISA (RISC-V compact extension), or by specifically creating ISAs for this reason (ARM with Thumb/Thumb-2; ARC with its special "long 32-bit immediate" extension to the opcode). Then, if code density still matters, how to benchmark it?

Which I think is what the above talk tried to do, removing the LTO, and just analyzing the generated output for each application (BTW, this is only a static analysis. Dynamic analysis is also important. And we have no idea about the impact of good code density strategies against performances).

Finally, yes, I've read that you think that GCC might be cause of RISC-V results. So, better optimizations might come for this ISA, and there are hints given at the end of the talk. However there are also suggestions to add new instructions to directly address some issues, which wouldn't be the case, because the most important part of RISC-V ISA are already frozen. This let me think that the room for improvements isn't that big. And, BTW, we don't know if GCC is really poor at generating good code quality for RISC-V.

Last edited by cdimauro on 31-Mar-2019 at 06:48 AM.

@hth313: up. Yes, I'm really interested on your opinion about my questions/doubt.

@cdimauro

Sorry for being a bit late with answering, I have not forgotten it. It was just a combination of that I thought I might repeat myself and I have been deep into 68k assembly the recent days.

Code density is very important in embedded as people tries to squeeze as much functionality as possible into devices while saving a few cents on each unit.

Why are ISA vendors into this? Quite simple, it is a huge and competitive market and all they want to earn money by taking as big share as possible. Each one wants to bring a better device to market and they do what they can to promote their device as better than the others. They all do this, in various levels of fair or misleading arguments, too often the latter.

I worked for years on making tools for these devices and sometimes they tried to make us say that this and that is better than others. We could of course not do that, in part as we want to keep a good relation with them all, but the truth is that it is not all that much difference in the end. Some are a lot easier to generate code for, so we liked them, (internally) of course. However, what I tried to say is that there are a lot of things that determine the outcome of the compiler, and the ISA is actually not that important in this case. Far more important is how well the optimizers are tuned. In other words how much work has been spent on it, and when you are at a decent level with that, how the application itself is written to suit the tools takes over, and this is by far.

You cannot imagine how much can be saved, sometimes in speed, but often size by analyzing the output of the compiler and adjusting things in the application code.

To take one example from about 15 years ago. I implemented a new backend for CPU12/S12/68HC12. It has a 16-bit accumulator and two 16-bit pointer index registers X and Y. It can address the stack and supports a very nice set of addressing modes, with index addressing, double indirections, via index registers and accumulator as displacement, stack pointer addressing, even load-effective address LEA instruction. (It has the coolest mnemonic set of the pack, what do you say about instructions named COMA, SEX and EMACS!) Yes, it has only three 16-bit registers, though the accumulator can be split in two 8-bit registers and they are usable in some addressing modes, quite cool, but it is basically a very good 8-bit ISA. I went to work and pushed the code generator and target specific optimizers technology I had at hand. I implemented everything I possible could without resorting to create new things that was not available in some form. I used some real customer code, mostly intended for some 8 and 16 bit device, not this one in particular. I made no changes to the application code.

The results? Well, one popular 8-bit device is the 8051, a very lousy instruction set from Intel. If you ask us which device gives the best code we would probably say what I said above, they are all basically the same. Well, with the exception of 8051 that is always worse than everything else and yes, ARM 32-bit that tends to be worse (there, I said it). Anyway, the CPU12 compiler totally obliterated the 8051, easily cut code size in half. Then I put it against some others and most noticeable Thumb, which can in some way be seen as the flagship product. Thumb has 8 32-bit registers and is a compressed instruction set. The Thumb should eat that poor three 16-bit register ISA (CPU12, basically an enhanced 6800 descendant) for breakfast, right? Not at all. I pushed the CPU12 to generate better code for every single customer module in the setup I had.

This was 15 years ago, things may have changed.

I suppose you can interpret this in different ways. One is that what I try to say, that the ISA is not that important. The other is that a CISC is better in code density than RISC. Another way would be that the application code was not written for a 32-bit device.

I leave that as an open question for now. I will hopefully be able to dive into 68k and RISC-V later and see if I change my mind and come out as a believer that CISC is the meaning of ISAs. For now I am happy to claim that it does not matter so much.

Regarding RISC-V, gcc is seen as the reference compiler for it. I would expect it to be good, but I have not yet looked at it.

Last edited by hth313 on 11-Apr-2019 at 03:16 AM.
Last edited by hth313 on 08-Apr-2019 at 12:53 AM.
Last edited by hth313 on 08-Apr-2019 at 12:53 AM.

@hth313: thanks for this amazing post (BTW, take your time: I also write when I've some spare time ).

It forced me to download and study the 68H12 architecture manual. I didn't know it before, and that's an incredibly well made CISC. Not so many registers, but A LOT of instructions and complex addressing modes: awesome! It might be the king of 16-bit processors (I don't like to classify it as 8-bit, only because the D accumulator can be seen as two 8-bit accumulators).

I wonder how it was possible to achieve better code density than Thumb-2 with half the registers for 16-bit opcodes, and 1/4 for the 32-bit ones. Might be due to the very powerful addressing modes, usable by most instructions (and there are many of them doing useful work!). Just a guess.

BTW, the code density could have been better differently arranging a few opcodes.

P.S. I had the chance to work with the 8051, because it was used A LOT when there was the explosion of cheap DVD players, and I was used to reverse-engineer parts of the firmware, and create patches to unlock functionalities or introduce small changes. Anyway, I didn't like it, and now I don't even remember how was the ISA.

@cdimauro

I had to edit the post as I incorrectly said Thumb2, it should of course be Thumb (Thumb-1, the previous variant).

Motorola would be happy that you call the 68HC12 a 16-bit, it was what they called it. It is a very nice rework of the 68HC11.

For some alternative nice 16-bit ISAs it can be worth looking at M16C (Mitsubishi, later Renesas) and MSP430 (TI). There may be others, these I am at least familiar with and they are both very good too.

@ne_one

[Quote]
First of all, given the fact that we're well beyond the 1980's, the OS should be largely CPU agnostic and the most compelling part of the product. Secondly (and counter to the same ageist argument), no one develops or markets a product based on the uniqueness of the CPU or its specs. Why? Because no one cares.[/quote]
Exactly what I was going to say, but you put it better.

Today, I'd have to go with X64, because of its ubiquity. Next week? ¿Quien sabe?

Now, given my choice, I'd like a 68k, debugged, on steroids. But, in the real world, no