@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro amiga gui which means mui is one and only thing from amiga os still usable.

Then tell me on which OS version I can find MUI and on which disk it's located.
Quote:

rest is too outdated and should be replaced by unix. as long as you don't have working mui clone you have nothing. and there are no reasons to switch toi x86/arm. so stop trolling start working on mui clone.

@geit

Quote:

geit wrote: @cdimauro Not sure what you want to achieve here.

Simple: the thread is talking about MUI, which is BOOPI-based, and I've given my opinion on this technology as well as a technical insight.
Quote:

Sure the method and attribute stuff in MUI is not very efficient. The main issue I have with your arguments is that you count bytes and CPU cycles. With a modern CPU (not talking ppc, even so ppc is helping a lot speed wise) all these arguments are pointless.

Sure, on a modern platform the inefficiencies of BOOPSI might be negligible, but this technology was introduced when we, developers, were counting bytes and CPU cycles.

Because the most common system was a 68000 machine running at 7Mhz and 512kB + 512kB of memory...
Quote:

A normal MUI-UI needs most CPU when the classes and instances are getting created. On very complex windows opening/resizing and therefor UI placements are requiring cpu power for a short time. A running MUI application does not require CPU at all. Interactions are (beside resize or a runtime change of the visible part of the window) mostly irrelevant.

See above: now maybe yes, but not at the Amiga time.
Quote:

The used memory for data storage and class code (e.g. the switch/case) is peanuts.

The problem with the class code is not (only) about the storage, rather about its runtime execution, because it kills the processor's pipeline, especially if you've a dependency chain to super classes when seeking for a property or method which was defined somewhere in the inheritance pyramid.
Quote:

Sure the (MUI) code could have been more effective. But this is what we have now. It has been growing over a very long time. It also failed in many places. e.g. by having uncontrollable requirements resulting in NList and other replacements, which are obsolete for years and should not be used in modern applications, but all in all the result is impressive and there is no competitor that even gets close.

Nothing to say about that, but that wasn't the point of discussion (and that's why I haven't quoted other parts).

@matthey

Quote:

matthey wrote: cdimauro Quote: It depends on processors' implementation, but overall the execution speed of indirect branches improved a lot even with deeper pipelines and longer penalties. High performance CPU cores improved "a lot" by throwing transistors at the problem since they already threw transistors at OoO but these cores are often many times larger and many times more expensive than the more popular and practical cores.

Yes, but that's what we have and... enjoy.
Quote:

The most affordable and popular in-order RISC cores still suffer from indirect branch performance. Indirect branch performance depends heavily on large amounts of cached data. A single VFT execution requires 3 separate data cache lines and a branch target buffer (branch cache) entry just to predict the last indirect branch target. Conditional branches have a significantly higher prediction percentage than indirect branches with just 2 bits of history data per branch. Predicting more than the last indirect branch target requires not only the branch history data but also the address of each indirect branch target. The most affordable and popular CPU cores have more limited caches than high performance cores and a VFT execution with data not cached can take hundreds of cycles and increase jitter for these often embedded cores. Even on high performance CISC cores with huge caches, best case performance is only a few cycles more than a condition branch but worst case performance is closer to more affordable cores.

Sure, but what's the alternative? The usual switch/case?

As I've said on another post, I can evaluate alternative to the same problems...
Quote:

cdimauro Quote: I don't share the same vision, rather the opposite. BOOPSI implies wasting a lot of data and code for achieving the same things that even the crappiest C++ (but it applies to any OOP language which has static compilation) compiler avoids. 1) You define properties/attributes by using tags -> not only you need an internal data structure for saving them, but you waste a lot of space by simply defining each member using tags. And the code which defines such properties has to scan the property ids to catch the good one and then takes proper actions -> a lot of other space (code) wasted. In C++ only the internal data structure is allocated and the constructor's code takes negligible code (unless you do more complex initialization. But this applies to a BOOPSI constructor as well). 2) You use tags for accessing properties/attributes -> same as before, because you need to scan the property ids and then take the proper actions to retrieve and give back the results. In C++ it's all about the usual struct->attribute_name (usually one CPU instruction, even on RISCs). Or even struct.attribute_name, because you can also have static objects which require no memory allocation at all. 3) You use tags for calling methods -> similar as before, because you need to scan the method ids and then call the proper routine. So, you end-up with the usual switch/case statement which needs instructions for being implemented and kills the CPU's pipeline by all such dependent comparisons, or have to use a indirect branch anyway when the method ids are too much widespread on the 32-bit id (this applies to the above property ids as well). And if you have multiple implementations (e.g.: method overloading) then if your current class hasn't overridden the method then you've to call the previous handler (e.g.: previous class) and repeat the same, until you finally find the method implementation. This both kills the processor's pipeline and the size of code. In C++ you need the VMT, which has a static size (one pointer per virtual method) and the client code is just the few instructions that you've already reported. 4) Callbacks requires the classic switch/case loop that goes on the same direction of the properties & methods, but this time it's all client-side. So, the application's code needs to take care of it. In C++ the application code needs to provide only the pointer to the callback, which will be save a list in memory. Very very efficient both on class and client side. Summing it all up: BOOPSI sucks. A LOT... AmigaOS tag lists trade performance for flexibility.

I don't see the flexibility. At least, it's only apparent.
Quote:

It's not the best system but not the worst either.

I've yet to find something worse.
Quote:

Multiple tags can be processed together with one function call avoiding multiple function call overhead.

Sorry, didn't get it: what do you mean with that? Because tags have to be processes one-by-one.
Quote:

Custom tags can be chosen with base+offset where the offset is the offset into an embedded structure and the base can be subtracted to give the structure offset.

This is up to who defines the tags and I don't recall if someone used it.

But it still requires checks to see if the specific tag is what's expected. Unless you want to remove all those checks as per Amiga OS "tradition", which I don't recommend.
Quote:

The original AmigaOS structure handling was more efficient and provided lightweight OO like functionality by embedding structures in other structures. For example, a device is a library that can use the functions of a library without any indirect branches (inheritance?).

Well, at the end it's an indirect branch, albeit it's predictable.

But that OS structure (which is base) was efficient.
Quote:

Efficiency doesn't get any better than this but there are extensibility concerns when structures grow which is why tag lists were created.

Extensibility could be achieved in a much more efficient way.

Tag lists also have a very nasty "feature": type erasure. You talked about OOP that could be difficult do debug: enjoy a system where you only have a 32 bit integer data type...
Quote:

BOOPSI performance can be criticized but the code is small, extensible, modular and likely could execute in parallel well with SMP. C++ has a performance advantage but statically linking code and data results in bloated executables which are less modular.

Why you've to statically link with C++? You can also use shared libraries.
Quote:

Comparing these two is difficult because they are very different OO implementations. BOOPSI was likely designed to be small, flexible and modular while C++ was likely designed for performance while trading executable size.

C++ was target to address every single requirement. It's up to the developer decided which of its feature to use or not.
Quote:

I believe both partially accomplished their goals. I have doubts that an OO C++ GUI implementation like Reaction or MUI would be possible on a 1MiB AmigaOS system.

You don't necessarily need a C++ implementation. Take a look at the Borland's Turbo Pascal implementation:
https://ia601902.us.archive.org/32/items/bitsavers_borlandturVersion6.0ProgrammersGuide_11460728/Turbo_Pascal_Version_6.0_Programmers_Guide.pdf
Pag.236 and so on.

So, you need to use a VMT and proper structure extension to get something which is MUCH more efficient compared to BOOPSI (BTW, Borland compiler sucked at optimizations).

@matthey

Quote:

Most of the technical challenged in the paper still apply today and are explained well. Sure, aggressive OoO CPU cores with more caches than memory of any Amiga C= sold are going to have good best case indirect branch performance which is most of the time. I suppose everyone should pay $100 USD for a CPU instead of $1 USD? Funny enough with more affordable in-order CPU cores, the smaller 1994 68060 from before the paper was written looks to me like OO VFT calls outperform clock for clock the most popular core in the world Cortex-A53 which is larger and much newer.

1. 68060 doesn't have ARMv8 128-bit SIMD i.e. per clock, 68060 is less multimedia capable when compared to Cortex-A53.

SiFive U74 doesn't have 128-bit SIMD, hence it's less multimedia capable when compared to Cortex-A53.

Both SiFive U74 and Cortex-A53 have 64-bit ALUs for a 64-bit instruction set while 68060 has a 32-bit instruction set.

68060 is missing 64-bit MUL.

68060 instruction cache can only provide 4 bytes of instructions per cycle.

68060 lacks a programmable microcode decoder for on-the-field firmware patching, hence the need for multiple mask revisions that fix the CPU bugs. 68060 lib needs to know the 68060 mask to apply the workaround fix.

With PiStorm-Emu68, I don't need to worry about 68060.lib.


2. RPi's Cortex-A53 has 1.4 GHz clock speed with a proven 1.8 GHz overclock. The A500mini's Cortex-A53 has 1.8 GHz.

IPC x clock speed = performance

Real-world Cortex-A53 is not limited by MC68060/ColdFire IV's clock speed.

MC68060's front-end transistor budget will increase when there's a large gap between the memory system and CPU clock speed.


MC68060 is NOT designed for high clock speed! Motorola has deleted 68060's features for higher clock speed ColdFire IV.

Motorola/Freescale is not crazy enough to hand design the layout for a CISC frontend RISC CPU with a Ghz range high speed.

CPU's design layout's density also influences reachable clock speed e.g. Zen 4C's higher density caused its clock speed to be less than Zen 4.

If the Radeon RDNA team needs AMD's CPU team for their high-clock speed design knowledge, then you're missing the knowledge base on high-speed designs.

Do you think pasting the 68060 design into a 7 nm process node = 3Ghz?

3. Cortex-A53 is replaced by Cortex-A55, Cortex-A510 and Cortex-A520. IoT SoCs are using Cortex-A55. Mobile Phone SoC has Cortex-A510 and Cortex-A520.

RPi 4B has Cortex A72 and RPi 5 has Cortex A76.

PiStorm16 (replacing CPLD with FPGA like on PiStorm32) is a new project to officially support RPi 4B on 16-bit Amigas.

Application processors = ARM orX86-64.
Single-purpose microcontrollers = RISC-V.

Last edited by Hammer on 07-Mar-2024 at 07:15 AM.
Last edited by Hammer on 07-Mar-2024 at 07:02 AM.
Last edited by Hammer on 07-Mar-2024 at 06:55 AM.
Last edited by Hammer on 07-Mar-2024 at 06:47 AM.
Last edited by Hammer on 07-Mar-2024 at 06:32 AM.

_________________
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)

@cdimauro

boring boring boring
want people to use amiga like os on x86/arm give them working amiga gui
stop writing bs start working on mui clone

@cdimauro

Quote:

cdimauro wrote: @geit Because the most common system was a 68000 machine running at 7Mhz and 512kB + 512kB of memory...

All Amigas that shipped with OS2.0 (or better) had at least 1MB Chip with an easy option to double that.

If you were using a naked A500+/A600 you barely got into contact with BOOPSI (maybe datatypes) and MUI was a non option anyways.

MUI it self has relatively small footprint as it relies on functionality already in the OS.
If it had been done in C++ it would have been bigger (even if good compilers had been available at the time).

So as usual just a bunch of couch coaching decades after the fact.

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

@Kronos

I agree, I have a few 68000 systems (Minimig with 3.5 MB RAM and A600 with 5.5MB) and in general a clean MUI setup is snappier and use just a little more RAM than Reaction counterpart. But then MUI offers rudimentary CX and ARexx interface to programs, as well as consolidated pub screen handling, window snapshot and lots more. Which for Reaction software must be specifically implemented in each and every program, with no consolidation at all. For MUi one can chose how much “bling & bloat� one can tolerate, for Reaction there are just a few selections and they don’t appear to make much impact on the memory footprint. MUI by default also looks more in line with the looks of 3.x while Reaction tend to look a bit “different�.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I still don't understand to this day why Reaction wasn't axed along time ago, and Mui embraced as the defacto standard.

Last edited by pixie on 08-Mar-2024 at 02:42 PM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro boring boring boring want people to use amiga like os on x86/arm give them working amiga gui

They already have it: Intuition, GadTools and BOOPSI were already fully ported.
Quote:

stop writing bs start working on mui clone

BS? Do you mean the one that you've written about it being part of the Amiga OS?

On which OS version it was introduced? On which disk I can find it? Care to give an answer PARROT?

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: @geit Because the most common system was a 68000 machine running at 7Mhz and 512kB + 512kB of memory... All Amigas that shipped with OS2.0 (or better) had at least 1MB Chip

There were people which upgraded the ROM on their A500/2000 or used Kickstart switchers.

That's the reason why I've written "512kB + 512kB of memory" without reporting its type.
Quote:

with an easy option to double that.

Older Amigas could have been expanded as well. The "only" problem was always the same: the money.
Quote:

If you were using a naked A500+/A600 you barely got into contact with BOOPSI (maybe datatypes) and MUI was a non option anyways.

Depends on the applications.
Quote:

MUI it self has relatively small footprint as it relies on functionality already in the OS.

That's why some applications were still usable even on base machines.
Quote:

If it had been done in C++ it would have been bigger (even if good compilers had been available at the time).

I beg to differ for the precise (technical) reasons that I've already reported before.
Quote:

So as usual just a bunch of couch coaching decades after the fact.

Hey, quiche eater: I was developing with OOP down to the lowest level when the Amiga OS 2.0 & BOOPSI weren't yet released by Commodore and you were still sucking your mother's milk.

Talk for yourself, kid!

Comparing compile time OO, where all possible classes are defined when the software is built, to runtime OO, where classes are dynamically defined at runtime is a bit chalk and cheese.

Runtime indirection in compiled time OO code is pretty much limited to deciding which concrete variant of an abstraction a factory needs to construct or performing a virtual function call. The latter is usually indexing a hidden table of function pointers that in turn is accessed via a hidden pointer in the data structure for the type. This has more overhead than a vanilla function call. It has more overhead than a simple indirect call through a pointer. A multiple step indirection is implied: dereference the object pointer to get the table pointer. Index the table to get the function pointer to call. Nevertheless, stepping on a pointer in a table for a machine with complex addressing modes is not that burdensome.

Contrast this with the BOOPSI specific realisation of runtime class definition, absolutely everything internally goes through many hoops. You gain the ability to define new types at runtime, but no ability for the language to enforce anything about those types. You lose everything else. Efficiency, type checking, etc.

Somewhere between the two extremes, sits Objective C.

_________________
Doing stupid things for fun...

@Karlos

mui is one and only thing from amiga os still usable
what you wrote no matter
it works 30 years ago works today and is still good enough

@cdimauro

gadtools was not enough even before commodore bankrupt
see devcon 93 docs

want people to use amiga like os on x86/arm give them working amiga gui
stop writing bs start working on mui clone

@ppcamiga1

Quote:

mui is one and only thing from amiga os still usable

It's funny to assert this when MUI is not part of AmigaOS and never has been. It's a third party system, that you had to pay for a registration key to be able to use fully and is built on top of BOOPSI. It is the standard UI toolkit for MorphOS, however.

AmigaOS uses Reaction instead. That's also built on top of. BOOPSI and if my recollection is correct, is an evolution of the ClassAct UI toolkit.

And there were others too. Triton is one that I remember from a handful of apps that used it.

They are all built on top of BOOPSI. So, is it that what you really want is a BOOPSI clone?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Comparing compile time OO, where all possible classes are defined when the software is built, to runtime OO, where classes are dynamically defined at runtime is a bit chalk and cheese. Runtime indirection in compiled time OO code is pretty much limited to deciding which concrete variant of an abstraction a factory needs to construct or performing a virtual function call. The latter is usually indexing a hidden table of function pointers that in turn is accessed via a hidden pointer in the data structure for the type. This has more overhead than a vanilla function call. It has more overhead than a simple indirect call through a pointer. A multiple step indirection is implied: dereference the object pointer to get the table pointer. Index the table to get the function pointer to call. Nevertheless, stepping on a pointer in a table for a machine with complex addressing modes is not that burdensome.

+1.
Quote:

Contrast this with the BOOPSI specific realisation of runtime class definition, absolutely everything internally goes through many hoops. You gain the ability to define new types at runtime, but no ability for the language to enforce anything about those types. You lose everything else. Efficiency, type checking, etc.

Exactly.

I can understand it if you've a (pure) dynamic language (like Python), but not with a statically compiled language.

I mean: if you already know upfront all data members and methods of a class, why on hell do you still need to define EVERYTHING dynamically, hurting both the consumed memory and the performance? That's really a dumb decision...
Quote:

Somewhere between the two extremes, sits Objective C.

Horrible syntax... -_-


@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro gadtools was not enough even before commodore bankrupt see devcon 93 docs

Then you've to ask Commodore to provide an extension of it, or some other library.
Quote:

want people to use amiga like os on x86/arm give them working amiga gui

Not needed: all of them already FULLY implement the Amiga GUI.
Quote:

stop writing bs start working on mui clone

What's not clear to you that MUI was/is NOT part of the Amiga, PARROT?


@Karlos

Quote:

Karlos wrote: @ppcamiga1 Quote: mui is one and only thing from amiga os still usable It's funny to assert this when MUI is not part of AmigaOS and never has been. It's a third party system, that you had to pay for a registration key to be able to use fully and is built on top of BOOPSI. It is the standard UI toolkit for MorphOS, however. AmigaOS uses Reaction instead. That's also built on top of. BOOPSI and if my recollection is correct, is an evolution of the ClassAct UI toolkit. And there were others too. Triton is one that I remember from a handful of apps that used it. They are all built on top of BOOPSI. So, is it that what you really want is a BOOPSI clone?

+2 & merged!

@Karlos

So AROS has broken BOOPSI support, so this why MUI can't be ported?

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

what?

@Karlos

Quote:

Karlos wrote: @ppcamiga1 So, is it that what you really want is a BOOPSI clone?

Sooooo, tell me what you want, what you really really want!

Last edited by agami on 10-Mar-2024 at 03:48 AM.
Last edited by agami on 10-Mar-2024 at 03:43 AM.

_________________
All the way, with 68k

@Karlos

mui is gui standard on amiga
it was before commodore
and is still good enough
want people to use x86/arm solutions start working on mui clone

@cdimauro

stop trolling start working on mui clone