Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: AmigaOS and the Console Development - Part 1  (Read 6757 times)

0 Members and 1 Guest are viewing this topic.

Offline ssolie

AmigaOS and the Console Development - Part 1
« on: September 30, 2015, 05:50:17 PM »
There is a new blog on how the Amiga's console evolved from 68K assembly to PowerPC.

See http://blog.hyperion-entertainment.biz/
ExecSG Team Lead
 

Offline eliyahu

Re: AmigaOS and the Console Development - Part 1
« Reply #1 on: September 30, 2015, 06:22:47 PM »
@ssolie

since i spend so much time in the shell, i'm looking forward to reading the next installment. the new console in final edition is so much nicer than kingcon (which i had used before). tony did a really nice job. :)

-- eliyahu
"How do you know I’m mad?" said Alice.
"You must be," said the Cat, "or you wouldn’t have come here."
 

Offline Pyromania

Re: AmigaOS and the Console Development - Part 1
« Reply #2 on: September 30, 2015, 07:20:02 PM »
Nice read.
 

Offline matthey

Re: AmigaOS and the Console Development - Part 1
« Reply #3 on: September 30, 2015, 08:06:16 PM »
Code: [Select]
   //    lea    cd_RastPort(a6),a1
    //    move.b    cu_Mask(a2),rp_Mask(a1)
    IGraphics->SetWriteMask(rastPtr, unit->cu_Mask);

    //    moveq    #0,d0
    //    move.b    d6,d0
    //    LINKGFX    SetDrMd
    IGraphics->SetDrMd(rastPtr, oldMode);

Progress! The replacement code is probably 1/3 of the speed of the original. Calling functions has lots of overhead. The macros in includes/graphics/gfxmacros.h could be used from C as well.

Quote
The original 68K assembler version of the console occupied 16,212 bytes. Compare that with the last 68K C version (V50.26) which was 42,564 bytes! It just shows how squashed the assembler version was (but that C version did have some debug code as well).

... Also, the assembler version had been written to minimise code size, rather than to optimise speed or code legibility.

The 68k assembler code was optimized for size instead of speed yet the example shown is much faster and much smaller in assembler. Why don't they just write the code in C++ (for better maintainability) also and see if they can make a semi-modern $2000 PPC computer slower than a 25 year old 68060?

Edit: Also, the 5 lines of assembler code, if properly optimized, should be 4 lines on an existing 68k CPU and could be 3 lines on an enhanced 68k CPU.

Code: [Select]
   //    move.b    cu_Mask(a2),rp_Mask+cd_RastPort(a6) ; this works on existing 68k
    IGraphics->SetWriteMask(rastPtr, unit->cu_Mask);

    //    mvz.b    d6,d0  ; ColdFire instruction
    //    LINKGFX    SetDrMd
    IGraphics->SetDrMd(rastPtr, oldMode);
« Last Edit: September 30, 2015, 09:53:48 PM by matthey »
 

Offline kamelito

Re: AmigaOS and the Console Development - Part 1
« Reply #4 on: September 30, 2015, 08:19:55 PM »
Nice read can we see episode 2? :)

Kamelito
 

Offline ssolie

Re: AmigaOS and the Console Development - Part 1
« Reply #5 on: September 30, 2015, 08:35:53 PM »
Quote from: kamelito;796655
Nice read can we see episode 2? :)

We are working on it now. It shouldn't be too long.
ExecSG Team Lead
 

Offline amigakit

Re: AmigaOS and the Console Development - Part 1
« Reply #6 on: September 30, 2015, 08:38:20 PM »
A very interesting read.  Thanks!
www.AmigaKit.com - Amiga Hardware/Software Dealer

New Products  --   Customer Help & Support -- @amigakit

USA Toll Free Order Tel: 1-888-698-6758
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #7 on: October 01, 2015, 01:23:44 AM »
Quote from: matthey;796652
Progress! The replacement code is probably 1/3 of the speed of the original.
And why do you bother? Is this in a speed-critical part of the device? Even worse, the assembler function does not go through an interface, hence anything that probably sits on top of SetWriteMask() is ignored.

Despite all that, the best optimization *here* would have been to simply drop the SetWriteMask() alltogether. The reason why the console.device uses this trick is to speed up scrolling in case the current color selection only requires a single plane to be modified, but everything on the PPC does not use planar graphics in first place, so any attempt to modify the write mask will make the code slower.

So yes, the translation to C code is probably well-intended, the 1/3 speed of a C function call is surely not relevant here. What is relevant is that this function is - for any sane graphics organization - useless and the whole code part that depends on this should have better been moved to trash in first place.

The speed critical part was not the function call, but the problem it solved in first place, a problem absent at the target platform.

Again, this rather shows that such a low-level view on optimizations is highly misleading.

Quote from: matthey;796652
Calling functions has lots of overhead. The macros in includes/graphics/gfxmacros.h could be used from C as well.
But would not have isolated the interface as well. Anyhow, neither the macro nor the function call is the right solution. The right solution here is to learn what the purpose of the write mask was in first place, and that it serves no purpose on the target platform.

Quote from: matthey;796652
The 68k assembler code was optimized for size instead of speed yet the example shown is much faster and much smaller in assembler. Why don't they just write the code in C++ (for better maintainability) also and see if they can make a semi-modern $2000 PPC computer slower than a 25 year old 68060?
With C++ code, the code would have been better, and probably faster than the C code, but as always, "faster" does not come with the language automatically, it comes with "understanding the problem" that is to be solved. Neither C, C++ or assembler do that by themselves. C++ helps because it allows you to get a cleaner view on the problem. Here, however, the actual problem was not understood correctly, and the code was "blindly" translated to C.


Quote from: matthey;796652
Edit: Also, the 5 lines of assembler code, if properly optimized, should be 4 lines on an existing 68k CPU and could be 3 lines on an enhanced 68k CPU.
That's just a useless micro-optimization. It wouldn't have created any noticable difference. Setting the mask on a planar graphics system - *that* makes a noticable difference. Instead, setting a mask on a chunky graphics system is a notable pessimisation because the graphics emulation has much more work to emulate the mask in first place. It is not "how to set the mask" that makes the console faster or slower.

It is "why do I need this code" that makes the difference. The analysis here should have showed "No, I do not need this code". In fact, this would probably have been more obvious if the code would have been in a high-level language in first place - instead the author got lost in details.
 

Offline kolla

Re: AmigaOS and the Console Development - Part 1
« Reply #8 on: October 01, 2015, 05:21:54 AM »
I just want a console-handler with a wee bit of scroll back buffer and tab competition that can be put in kickstart even on a 68000, for those occations when I boot without startup-sequence. Or rather, tab-expansion in shell and only scroll back buffer in console-handler. For what it is worth, AROS has something like this already, "real" AmigaOS is lacking behind these days.
« Last Edit: October 01, 2015, 05:52:21 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline matthey

Re: AmigaOS and the Console Development - Part 1
« Reply #9 on: October 01, 2015, 06:32:20 AM »
Quote from: Thomas Richter;796669
And why do you bother? Is this in a speed-critical part of the device? Even worse, the assembler function does not go through an interface, hence anything that probably sits on top of SetWriteMask() is ignored.


The macros are perfectly legal and they are a lot faster. Is it better coding practice to use slower code for little if any benefit? It is true that the macros don't go through the LVO so a setpatch couldn't replace the code but this is true of much of the AmigaOS. It didn't stop P96/CGFX from patching everything. Your newest layers.library still uses the Forbid/Permit macros in most places instead of the function calls. Also, some of your layers.library function calls go through the LVO and some use a regular BSR instruction. It looks pretty inconsistent to me.

Quote from: Thomas Richter;796669

Despite all that, the best optimization *here* would have been to simply drop the SetWriteMask() alltogether. The reason why the console.device uses this trick is to speed up scrolling in case the current color selection only requires a single plane to be modified, but everything on the PPC does not use planar graphics in first place, so any attempt to modify the write mask will make the code slower.


AmigaOS 4.x can be used on a CSPPC with AGA graphics so maybe it is not completely useless. There is sometimes a cost to backward compatibility.

Quote from: Thomas Richter;796669

So yes, the translation to C code is probably well-intended, the 1/3 speed of a C function call is surely not relevant here. What is relevant is that this function is - for any sane graphics organization - useless and the whole code part that depends on this should have better been moved to trash in first place.


A couple of functions aren't going to make much of a difference. I just found it funny that the example wasn't consistent with the article comments. It is also funny that the 68k AmigaOS with all its optimizing for space really wasn't so well optimized from their example either.

Quote from: Thomas Richter;796669

The speed critical part was not the function call, but the problem it solved in first place, a problem absent at the target platform.

Again, this rather shows that such a low-level view on optimizations is highly misleading.


Yea, but you wouldn't have removed the call because the code is working. I know you too well. Making the safe optimizations to gain what I could while leaving planar support intact sounds pretty good to me. It would be better if the code was in C with the programmer using the macros and the compiler doing the optimizations though. This is not speed critical code after all ;).

Quote from: Thomas Richter;796669

With C++ code, the code would have been better, and probably faster than the C code, ...


Not likely faster. Not likely at all. Better is debatable.
 

Offline olsen

Re: AmigaOS and the Console Development - Part 1
« Reply #10 on: October 01, 2015, 11:10:37 AM »
Quote from: matthey;796682
AmigaOS 4.x can be used on a CSPPC with AGA graphics so maybe it is not completely useless.

Wait -- the operating system allocates chip memory bitmaps in a particular manner. The bitplanes are interleaved, which means that a single line of the bitmap is stored consecutively in memory. See the Leo Schwab article on page 10 for an explanation of how interleaving works: https://archive.org/details/AmigaWorld_Tech_Journal_Volume_2_Number_1_1992-02_IDG_Communications_US

This is an optimization to allow for blitter operations to move bigger chunks of data in a single operation, rather than breaking them up into several separate operations. For example, if the bitmap is non-interleaved, the blitter is reinitialized and restarted for each single bit plane. In interneaved form the blitter is initialized and started only once. As a side-effect, the update minimizes flickering. The update can also use more bandwidth (one big chunk vs. up to 8 smaller chunks).

Now, what exactly will SetWriteMask() do in this situation? It has the effect of making display updates more costly if an interleaved bitmap is used (which is the standard case). Instead of moving one consecutive chunk of bitmap data, the blitter operations have to be broken up into individual planes again. Available bandwidth is used less effectively. This can be noticeably slower.
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #11 on: October 01, 2015, 03:51:52 PM »
Quote from: kolla;796680
I just want a console-handler with a wee bit of scroll back buffer and tab competition that can be put in kickstart even on a 68000, for those occations when I boot without startup-sequence. Or rather, tab-expansion in shell and only scroll back buffer in console-handler. For what it is worth, AROS has something like this already, "real" AmigaOS is lacking behind these days.

What's the problem with ViNCEd?
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #12 on: October 01, 2015, 04:13:29 PM »
Quote from: matthey;796682
The macros are perfectly legal and they are a lot faster.  
Please define "a lot". Or rather, take your time and benchmark console with the macro and without it, measure the difference and tell me. I haven't done that, admittedly, but just from your gut, what would you expect? 10% speed improvement? Not seriously. My gut feeling is: Below the statistical error. Way below. Don't waste your time in details.  
Quote from: matthey;796682
Is it better coding practice to use slower code for little if any benefit?  
Compatibility? Readability? Maintainability? Actually, that's quite worth something. What I do not like about macros is that they require knowledge of the implementation details to work. In other words, they expose the internal structure you are manipulating to the compiler, making it impossible to change that without recompiling the code. Again, admittedly, it's already too late for graphics to fix that, graphics is all over with code that exposes internal interfaces where it should not, but please! can we avoid this problem in future code somehow? There are interface functions, and here we have a perfectly fine "setter" function for an internal property. It's good practice to use that.  
Quote from: matthey;796682
Your newest layers.library still uses the Forbid/Permit macros in most places instead of the function calls.  
No. Actually, in one single place, and that was replaced by a semaphore in Os 4 anyhow (by Olsen). Again, you're looking at the details and not at the problem. The problem that is solved here (in the function using the Forbid()-locking) is creating a layer-info global stack of cliprects, thus avoiding a wasteful memory allocation, and hence avoiding memory fragmentation whenever possible. That makes a difference, though probably not for layers directly. Ideally, this could be a semaphore, but given that only a single pointer linkage requires protection, this might arguably an overshoot. The real reason why there is no semaphore is that back then I didn't know where to put that semaphore. It should be a layerinfo-relative semaphore (since that's where the cliprects belong to), but there is no room in the layerinfo anymore. It could be a global semaphore, but that means that one layer info can lock out another layer info, same as with forbid-locking. So there is not really a clear advantage of semaphores here either.  
Quote from: matthey;796682
Also, some of your layers.library function calls go through the LVO and some use a regular BSR instruction. It looks pretty inconsistent to me.
That depends on the function, and is pretty much a choice the original designers of layers took (mostly). Given that layers is patched over by many places, it's not a good idea to mess with that overly. If you have a patch on top of a layer function, you'd probably better make sure to know when precisely that is called, and the patch - in some cases - should not be called for internal functioning of layers. Again, I outright admit that I do not understand the logic by which layers does or does not call through its external interface, but given that patches and programs may depend on exactly the choices that have been taken by our ancestors (ehem), it should probably stay that way.    
Quote from: matthey;796682
A couple of functions aren't going to make much of a difference. I just found it funny that the example wasn't consistent with the article comments. It is also funny that the 68k AmigaOS with all its optimizing for space really wasn't so well optimized from their example either.
No, it's not a particularly good example. Or rather, it wasn't made quite clear by the article why that choice was a good choice and helped making console better. From a software design perspective, it *might* have been a good example, but it would have been an even better example to explain why that function call should be removed in first place.  
Quote from: matthey;796682
Yea, but you wouldn't have removed the call because the code is working. I know you too well. Making the safe optimizations to gain what I could while leaving planar support intact sounds pretty good to me. It would be better if the code was in C with the programmer using the macros and the compiler doing the optimizations though.  
Maybe I've done too much C++, but I wouldn't pick macros if there is a call interface. Macros are fine for internal interfaces, really. But for something you expose to the global world, they are a particularly bad choice. Again, too late for poor gfx anyhow.    
Quote from: matthey;796682
Not likely faster. Not likely at all. Better is debatable.

"Better" requires a metric you measure quality with (oh boy, I'm again talking as if in a JPEG meeting again, same problem all over!). "Running speed" and "code size" are two of them, but not necessarily the most important ones. Something I did not understand back then either, again admittedly. But if you want to maintain code over a longer period of time, and want to update it if you need to, you'd better make sure that you have robust interfaces and a well-documented code, and code that speaks for itself. Assembler doesn't quite fit into this picture, and macros neither.
 

Offline Georg

Re: AmigaOS and the Console Development - Part 1
« Reply #13 on: October 01, 2015, 05:05:58 PM »
Quote from: Thomas Richter;796700
What's the problem with ViNCEd?


The name!!! The worst one you could possibly come up with. Really!
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #14 on: October 01, 2015, 05:21:43 PM »
Quote from: Georg;796704
The name!!! The worst one you could possibly come up with. Really!

Would "VeryNewCon"  be better? That's the initial name it was.