@matthey

Quote:

AOT translation of code ahead of time has the advantages of being able to perform some static data endian conversion and being able to perform more optimization than JIT where we see ARM performance suffering from lack of instruction scheduling. It may be possible to better optimize the JIT hot spots but trying to optimize code in heavy use is undesirable. Trace driven optimizations can improve JIT performance but increase startup latency and jitter while also using more memory. There are not many virtual systems anymore like JAVA virtual machine (JVM) but AOT compilation is used by the Android Runtime (ART) replacing Dalvik JIT.

You're the second person to willfully conflate Java as an example of why X is better than Y in a discussion about something else. The primary reason for AOT compilation of Java isn't actually overall execution performance, it's performance per watt and minimising battery drain. There's no question that any form of runtime analysis or interpretation of code will use more CPU time than direct execution of the same/equivalent code. The improvements to the perfomrance in mobile applications often aren't that big (with a few exceptions) but the reduction in actual CPU time and the impact that has on battery life is much more apparent and measurable.

For a non-battery powered device, the question you need to be asking is, does the additional CPU overhead of the activities associated with JIT detriment the performance to the extent of degrading user experience?

Who finds UAE on their PC or their new PiStorm/Pi 4 accelerator "too slow" ? Who found Amithlon too slow?

The only problem I foresee is that software will emerge that no physical 68K can run acceptably. But to be honest, that's already a thing. How much faster is a 100MHz 68060 than a chip-ram-only 14 MHz 68020?

Last edited by Karlos on 22-Dec-2024 at 07:24 PM.
Last edited by Karlos on 22-Dec-2024 at 07:20 PM.

_________________
Doing stupid things for fun...

@matthey

Quote:

AOT translation of code ahead of time has the advantages of being able to perform some static data endian conversion and being able to perform more optimization than JIT

I don’t see much place for AOT benefits in case of amiga software for m68k, mostly due to lack of sufficient amount of metadata in executables. Furthermore, things like postponed writes or instruction reordering in order to get more performance can be achieved in JIT too. So no, I do not see a necessity for AOT translation.

@michalsc

Even with more metadata, the example given was Java which is simply not comparable IMHO. Java bytecode isn't comparable to object code that is potentially full of references resolved only when code is loaded into memory. All the symbolic data in a java class are all neatly packaged up for the runtime or compiler to decide what to do with and java lacks anything comparable to the sorts of indirect addressing and computed jumps that native object code may contain. The same sorts of things that make disassembly hit and miss will also frustrate AOT translation.

Last edited by Karlos on 22-Dec-2024 at 10:06 PM.

_________________
Doing stupid things for fun...

https://x.com/amigang/status/1870961006433976491?s=61&t=3D3V-sMRUBLE9C542stm_g

A1200NG motherboard revision 3A

The A1200NG motherboard fits into original and remake Amiga 1200 desktop cases. The ports align with the holes in the case using the supplied backplate.

Features:
Games menu: add, edit & launch ADF/HDF/WHDBoot games, scene demos & apps (OCS, ECS, AGA).
AmiBench: 1080p screenmode with 32-bit icon set. Run Classic 68k programs.
Dual 9-pin Joystick Ports: accepts Commodore compatible joysticks ¹
HDMI compatible 1080p output: plugs into HDMI compatible television or monitor
Wireless Internet: connects to AmiSphere for system updates and email
Bluetooth: optionally output audio to Bluetooth speaker
34-pin Floppy Header: read and write to real 880K floppy disks (Greaseweazle compatible)
RS232 Serial Port (DB25)
System RAM: 4GB in total. 1GB Fast Memory allocated for AmiBench.
Hard Drive: 64GB or 128GB option.
Internal USB headers for connection of optional USB to SATA or USB to IDE adapters.
External USB headers for connection of DrawBridge USB floppy disk drives, Mice, MIDI interfaces, Flash Drives.


Pre Installed Software:
AmiBench Release V46
Personal Paint (PPaint) V7.4
OctaMED V8
Directory Opus V4
Final Writer V7.2
YAM email client
JST
Utilities: EaglePlayer, HippoPlayer, Dock, Clock, Calendar
Games: Super Skidmarks, Thunderhell, Virtual GP, T-Racer


What is included?
A1200NG motherboard
ARM module (H618 Quad Core 1.5Ghz/4GB RAM)
64GB or 128GB micro SD card
HDMI cable with backplate (fits underneath floppy drive)
Metal backplate for ports
Power Supply Unit
Printed Colour Manual
A1200NG case badge
Silver foil serial case sticker
Hex bolts and screws


Product options:
A1200 9-pin joystick port 1 board
A1200 LED adapter module
A1200 motherboard insulation layer


Rear External Ports:
9-pin Joystick
USB ports
25-pin Serial Port
Left / Right Audio RCA audio out
Composite (no driver support)
Power In Port
Compact Flash reader


Internal Connectors:
34-pin Floppy Disk Drive header
USB header (dual)
A1200 LED module header
A1200 keyboard ribbon header (31 pin)
4-pin Power header for optional floppy disk drive
4-pin Power header for optional SATA/IDE hard drive
2-pin Fan header

_________________
AmigaNG, YouTube, LeaveReality Studio

@Karlos

Quote:

Name one single feature that's not simply an incremental improvement over what was already possible with 3.x/68K and that *cannot* be achieved with 68K because of some architectural improvements that migration to PPC enabled.

I can think of some but they all rely on being in the hardware implementation. First I would say FPU. Not all 68K has FPU. FPU is standard on PPC. (Ignoring that weird A1222 CPU). This extends into compiling. OS4 C code can expect and use FPU operations. While on 68K you needed compile separately for FPU, on PPC you just use floats in your code and forget about it. However, the 64 bit PPC floats do look inferior to 80 bit 68K floats, which looks like another RISC limitation.

Second is vectors. Now the X1000 is the last to have it and the current flagship X5000 has none. But, on the hardware level, PPC has vectors and 68K doesn't. However, this really does need vector specific code. So it's a bit like FPU on 68K.

Third, I can't really think of much else really, but technically PPC would be much advanced over 68K. Another thing is memory and using DDR. However, the Vampire claims to be faster than PPC, since it uses a superior DDR RAM.

Quote:

I can't think of any, not here in 2024. Really there should be SMP and full 64 bit support now. Where is it? Sure there are improved API for almost everything, but they are we evolutionary, not revolutionary.

They didn't get onto that early enough. Even PPC can almost make no sense, because OS4 had no compatibility with PPC apps. What was the point? I don't consider 3rd party downloads, I only consider what is standard in the OS. How did they release a PPC OS, that had no compatibility with Amiga PPC software? The company that ported the OS to PPC didn't even make it work with their own PPC games or even port their games over! After that blunder the writing was on the wall!

Anyway, they really needed a clean updated API for PPC, that was SMP friendly or encapsulated sensitive operations into a private API. While keeping Exec and the like as it was for common 68K recommended hacking procedures. They got somewhere in the middle. Compatible enough with 68K. Except when they purposely broke it such as corrupting the clean GetCC() function or broken trap code exceptions. And crippled ExecSG by being too close to 68K and dragging over the old Forbid/Permit hacks recommended.

Quote:

By contrast the (real) 68K has no option to run 64 bit because no 64-bit variant of the CPU exists. However, you *could* make use of extra memory by using such a private mapping scheme when running in virtuo on a 64-bit bare metal emulation.

Doesn't the Vampire feature a 64 bit CPU? Well the 68080, if it could be considered a real 68K, since it's not an official Motorola MC 68K designed by the 68K team and fabbed into an ASIC.

Also, the Apollo 68080 also has AMMX. Vectors for 68K. Intel inspired they may be. That makes 68080 way superior to the A1222 and X5000, because it has vectors, and they don't. (Ignoring the weird hybrid FPU/SIMD in the A1222 CPU.)

@Karlos

Quote:

I'll die defending this hill. I don't think there's anything daft or outlandish about the idea. You need a low level HAL that embeds the JIT emulation and exposed certain things to the OS for use, e.g. ability to map private memory, devices, etc. Everything else can run within then 68K "box".

Hehe. I know. I was half hoping that someone would argue with you for entertainment value.

Quote:

You can't fully modernise without taking away most of the compatibility and things that people genuinely love about the platform.

And that's part of why AmigaOS is firmly stuck in the past. Wanting to hold onto the past too much compromised AmigaOS 4, hampering progress (while not holding onto the past hard enough for the hard-core retro-Amiga guys).

@matthey
Quote:

There is so much discussion about porting the AmigaOS to other architectures but all ports do is divide the Amiga user base with hardware that is less popular than the 68k Amiga.

Nah, it won't divide the user-base even further. If AmigaOS 4 were ported to ARM, likely all AmigaOS 4 users would migrate...except for ppcamiga1 (but prepare for a new avatar called armamiga1).

@Gebrochen

Quote:

Interesting Point Of View, not necessarily accurate...[quote] I'm using my own analytics data as a proxy for overall interest in AmigaOS 4. Not perfect, and you can expect my numbers to be significantly lower than overall interest in OS4. Nevertheless, the numbers are really low. Bear in mind that only AmigaOS 4 fans would be interested in signing up. The classic 68K community is far larger (albeit still small). If that's still too weak for you, then cast a wider net. Have a look at interest in AmigaOS related youtube channels, and the number of daily/weekly/monthly logged in users on forums like this one. [quote]In your newsletter case, I just noticed I'd have to sign up, I barely like signing up to begin with to anything new, as there are already lot of damn passwords to recall for other more pressing things in daily life. Is there a way to bypass signup, and yet still view the newsletter for example?

It's an email newsletter. No password needed, but there's no way for me to email you if you never give me your email address.

I can't remember all my passwords either, which is why I use a password manager.

Hans

Last edited by Hans on 23-Dec-2024 at 09:22 AM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@amigang

Sounds nice. At this stage, it would probably be better to start a new thread when the next tid-bit of news drops, because this one got derailed multiple pages ago.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

I will be still using ppc.
But I may consider use of x86 or arm amiga like solution
if it will be fast native up to date with future at rational price.
It have to have decent web browser.
It have to be no more than 15 years behind windows.
I'm not interested in worse retro with x86 or arm.
It is not interesting.

@ppcamiga1

Quote:

if it will be fast native up to date with future at rational price. It have to have decent web browser

Just use Linux, BSD, Android or Mac then. Muppet.

Better still, use AxRT. It has all of the above and the Amiga look and feel.

And of course, chunky pixels

_________________
Doing stupid things for fun...

@Hypex

The FPU is not revolutionary. It was always optional for 68K. It's good that it has always been a feature of PPC - right up to the point someone decided to use an incompatible one. You see where this is going.

SIMD is also not revolutionary. While there are no SIMD on traditional 68K, if you want to add Apollo to the mix, it has its own AMMX. Nevertheless this is a weaker example than the FPU since a significant proportion of PPC machines do not have a vector unit either.

All said and done, however, if your goal is to translate 68K object code to native, a sufficiently sophisticated JIT may be able to auto vectorise various simple loops just like a compiler does.

A more likely use case would be native passthrough. If you permit the use of native code for low level tasks, you could use it in various libraries and drivers.

_________________
Doing stupid things for fun...

@Hans

Quote:

And that's part of why AmigaOS is firmly stuck in the past. Wanting to hold onto the past too much compromised AmigaOS 4, hampering progress (while not holding onto the past hard enough for the hard-core retro-Amiga guys

As someone who actively develops within the scene, I'd be interested to know what your views are on what OS4 should be, if backwards compatibility were purely offloaded to (RunIn)UAE.

Some of my thoughts are covered by the following questions.

Where does the boundary between Amiga-like end and posix-like begin? Could a system be both?

If your system ends up being able to port software readily from other platforms, but harder to port from old AmigaOS due to the changes required to modernise, does it encourage or discourage native development of equivalent applications?

Would we end up with a better Amiga-like platform or obscure GNU/Linux type platform but without the robustness?

If the only way to run legacy AmigaOS applications (including older 32-bit PPC binaries for WarpOS etc) is by whole system emulation and newer software ends up being mostly ports of software from Linux, etc, at what point does it just become better to just run Linux and UAE on commodity hardware than on expensive PPC kit?

One thing to say about MorphOS, the guys have leaned hard into extracting as much as they can from the single core 32-bit PPC left behind by Apple and keeping compatibility with the legacy.

If the point ever comes that your system is something POSIX like with a bunch of Amiga API on top to support legacy style interfaces, isn't AxRT already there?

_________________
Doing stupid things for fun...

@amigang

Well I think Karlos is right, I am not "the target audience".

Buying an overpriced EMU box that can't do anything I couldn't do by slapping together parts based on some ancient PC or rPI? Not my style.

Dealing with the horrible ergonomics of a KBD case (which should have died 40 years ago)? No way.

Downgrading to AOS3.x or AROS? Nah...

Downgrading both CPU and GPU performance ( 1.5GHz SoC usually found in $20 TV boxes)? I don't see the point.

All for what? So that I can play ancient games a little bit easier? Or that I maybe can enjoy some selective "not NG but still kinda NG" features that might be exclusive to this obscurest of the obscure splinter faction?

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Begging your pardon, but how is AxRT a downgrade from a 32-bit single core only ABox operating system running on left over apple crumble?

Last edited by Karlos on 23-Dec-2024 at 10:28 AM.

_________________
Doing stupid things for fun...

@Karlos

Where does it mention AxRT in the spec sheet?

If I wanted to go that route, plenty of better Linux systems to choose from.

And even if, with an SoC that weak you'd need to push it quite hard to be (let alone feel while running a full Linux) faster in real life.

Last edited by Kronos on 23-Dec-2024 at 10:48 AM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

I'm not talking about the spec sheet, I'm talking about the downgrade to AROS from MorphOS.

AxRT is an outgrowth of AROS, without any of the legacy limitations imposed by the core OS because it's gone. You can compile system friendly AmigaOS applications for it relatively easily and run them on a 64-bit SMP capable platform, with the Zune/MUI interface UX we are all familiar with. And you can, of course, just compile all the modern software you want from Linux, because, well, it is Linux.

In short it has all the advantages over both PPC/NG straight out of the box. It's already done the "hard decision" bit of kicking legacy binary compatibly to the kerb in favour of modernising.

You might not like the specific path it took to get there, but it fulfils the "NG" premise in full. What's more, I dare say it's easier to source port Amiga applications to than a fully reworked SMP/64-bit version of OS4 or MorphOS would be. I don't think they'd be any more backwards compatible either. Though it's difficult to say, since neither has achieved it.

I really can't understand why the hamster isn't all over it, it's everything he keeps demanding people make.

Last edited by Karlos on 23-Dec-2024 at 11:02 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

I'm not talking about the spec sheet,

So you are replying to a post completely ignoring context to insert some OT stuff eager to proof a point noone cared about?

Sure AxRT is interesting but in it's current form it offers little to nothing to make me consider switching (might change, but I won't hold my breath).

In a similar vain I recently had a conversation with Mr Schulz about EMU68/piSTORM and while it did fix some misunderstanding on my side and even sparked some interest it clearly still offers to little in real life benefits over my old G5.

Sure raw performance of that rPI is superior and if it was fully utilized it would also be as an Amiga. And sure all the features from MorphOS could be ported over, and yes at that point switching would be a no brainer.
I just don't see it getting there anytime soon, I'll even doubt there will ever be a serious attempt to get it there.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Karlos

Quote:

As someone who actively develops within the scene, I'd be interested to know what your views are on what OS4 should be, if backwards compatibility were purely offloaded to (RunIn)UAE...

I don't have all the answers. What I can tell you, is that when I've asked about better ways to implement certain things, the reason why it was done in a difficult way was because compatibility with the classic Amiga chipset had to be maintained. Classic Amiga hardware is so different from the PowerPC motherboards that we're using, that it takes some effort to bridge the gap.

Updating the GUI style guide and making UX improvements seems to be heresy to some. There's always someone who complains that you've lost part of the character of the OS when you change something. Remember the arguments over having a drawer of prefs programs vs using a unified prefs program (like MorphOS)?

There are also those who want me to bend over backward and practically sacrifice myself for the cause of enabling modern GPUs to warm-reboot. Yep, warm rebooting is such a "killer feature" that no expense must be spared to maintain it.

None of this has anything to do with POSIX compliance or potentially becoming a Linux clone. It's about clinging to the past so hard that you can barely move forward.

If it were up to me, we'd ditch classic hardware compatibility, including support for planar pixel formats, and move the base OS forward. Old OS friendly software could run in a sandboxed environment, and anything tied to classic Amiga hardware (or planar pixel formats) would need to be run in a full on machine emulator (with that fancy rabbit-hole feature, to make it feel integrated).

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

In which ways would you seek to move the base OS forwards? It's a hugely weighted question, but if the direction is towards 64-bit and SMP there are existing experimental AROS iterations with that and of course AxRT which just dumps the base OS entirely and replaces it with something that's already walking the walk and provides a bunch of (as far as is practical) Amiga compatible API on top.

What you seem to describe as an obdurate clinging to the past of many users holding the system back is just a manifestation of the fact that (these) users want an "Amiga". Even though the hardware has been replaced and all the 68K ASM from the original OS replaced by C, to them it's still an Amiga. But why? It's the broomstick that had the head and shaft replaced at different times. What about it is still an Amiga? That's a completely subjective point. My view is that only the original hardware is an Amiga and everything else is a "compatible", but that's just a very factual characterisation. I don't expect everyone to share it.

Perhaps ppcamiga1 isn't so bonkers. I mean, he is a complete fruitcake, but when he talks about "why PPC", it's all big endian 32-bitness. That's literally the only thing from the original Amiga hardware architecture that has persisted. And as we both know, when writing code in C, you have to try to make endianness an issue, either by messing around with different sizes data at the same address / unions or when reading / writing data in a particular fixed byte order.

It seems to me that the users/devs who want a clean break with the legacy in order to move forwards already have that option. So what's stopping them?

_________________
Doing stupid things for fun...

@Kronos

I would be surprised if MorphOS didn't migrate to ARM native at some point.

We can make AxRT relevant to this thread if it bothers you that much. What's stopping an arm native build working on this new hardware? Nothing really.

Is it the best possible arm hardware for that? Maybe not. Would it be a better overall utilisation of that arm hardware than a direct port of either NG OS to arm native? Yes, provided you don't mind the lack of binary compatibly, etc.

Is it a reasonable hardware platform to run 3.x / 68K on? Sure. There are more performant options but I don't expect it to be anything other than *significantly faster* than any existing 68K silicon.

Does it tick all the retro nostalgia boxes? I think so. YMMV.

_________________
Doing stupid things for fun...

@Kronos

There is more planned than just running some aros apps on linux. All Apps will have amigaos like theme and behavior and there will be a amiga desktop as real linux desktop, propably scalos. So look & feel will be much more amiga-like than anything that was possible before.

Downgrading to AROS? From what?

Basically all NG systems are similar and a different MUI implementation is no advantage in real world

Last edited by OlafS25 on 23-Dec-2024 at 12:31 PM.