Click Here
home features news forums classifieds faqs links search
6066 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)



Lost Password?

Don't have an account yet?
Register now!

Your support is needed and is appreciated as is primarily dependent upon the support of its users.

Main sections
OS4 Zone
IRC Network
AmigaWorld Radio
Top Members
Amiga Dealers
About Us
Terms of Service

IRC Channel
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
79 crawler(s) on-line.
 23 guest(s) on-line.
 0 member(s) on-line.

You are an anonymous user.
Register Now!
 michalsc:  5 mins ago
 afxgroup:  7 mins ago
 Cammy:  9 mins ago
 OlafS25:  10 mins ago
 amigakit:  13 mins ago
 Amigamia:  16 mins ago
 Jasper:  45 mins ago
 nicole:  1 hr 17 mins ago
 amipal:  1 hr 24 mins ago
 Akiko:  1 hr 29 mins ago

/  Forum Index
   /  Amiga OS4.x \ Workbench 4.x
      /  A-EON is internally testing Alpha releases of their own operating system
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 )
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Jul-2021 16:21:22
#141 ]
Joined: 8-Jun-2020
Posts: 48
From: Unknown

there's no "new thing". It's just blown up speculation started by based on nothing but two leaked message-board screenshots which actually don't contain concrete info about a new OS but merely about a new Enhancer installation process which of course requires AOS4 and results in a folder setup which makes Enhancer somewhat appear like some sort of OS distribution at best.

 Status: Offline
Profile     Report this post  
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Jul-2021 21:54:56
#142 ]
Joined: 14-Feb-2010
Posts: 92
From: Texas


What they wanna do i think is another Commodore usa OS ... Linux with a icons set amigalike and a background with a boing

I liked the CommodoreOS project. I actually used it as my Linux system at the time, and I used it for as long as I could before having to switch to Linux Mint, which is the Linux distro I still use.

 Status: Offline
Profile     Report this post  
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 13-Jul-2021 16:42:17
#143 ]
Elite Member
Joined: 6-May-2007
Posts: 10308
From: Greensborough, Australia


the problem, you can run into, or should I say, trap is that now everything is reference, is you now use setter and getters, that?s not ideal. they are slow.

That's the OOP way. And what datatypes are designed around. But how else would you do it? Changing a direct value? Anything that uses a function to change a value would be slower than changing it direct but direct changes needs arbitration.

the biggest problem in my option is the reply message design, the idea that message need to be send back to sender, I understand they wanted to reuse messages, it had some advantages, like memory allocation can be slow, however I expect waiting for task for waking up the right process given task priority, is some what slow too, 2en advantage to old design now memory fragmentation, that?s not issue anymore, now that we have better memory allocator.

Well, the message doesn't travel in a one way street. And inherent in the design is notifying the sender when the message is finished with. It would be hard to avoid because some things like devices use it to signal completion of work.

2en problem is task priority and message queuing, in my option it be good idea if the scheduler know what process had problems processing / keeping up with message queue, message storms seems to be the course of many lockups. I think having a message counter per process be good idea, as quick way to lookup process that need a bit more time, to keep up. Also if there are message that can be dropped, expired, it be nice if the kernel can remove this. (For example, no point giving process time, if it has not processed the mouse move events.) for example task/process might be busy rendering a large image, and its not in the get message sub routine. and also at some point the kernel should determine, the process is a zombie, and block sender from sending new message to it, that are never going to be processed. if the system gone in dead lock.

The need to reply should reduce these issues since the sending process would usually be waiting for a reply before sending more. Also, I note messages lack a time stamp. There is no standard heart beat tick signal used to verify if a process is still alive so the OS needs another way to check for a dead process. One way would be to check if a process constantly uses up its quantum but all heavy processes would do that.

AIX uses R1 as stack.
AmigaOS4.1 i'm pritty sure uses R9

OS4 follows the SystemV ABI. So uses R1 for stack as well.

PowerPC uses R9 for parmiters, and R9 is stack on PowerPC.
(and you see r31 being used, its temporary)
a stack as in Z80 dont exist, I think the necessity of stack disappeared as permitters will be in data cache anyway, and also Push, and Pops like on the Z80 is a pain, because needs to take data out the revere order as the data is stored. you don?t need to do that if it?s using a GPR. (Indirect addressing).

IIRC PPC ABI has 8 registers parameters. Despite having 32 registers. So any more needs to be stacked. Where as 68K ABI, where ever it's from, could have up to 15. Things like BlitBitMap() break on PPC as the ABI can't fit it all in registers so on PPC it's inefficient. But no less than x86 would be.

Also, being a stack, needing to reverse order is expected.

It does have this, reverse load, store instructions. You need to drop down to assembler to use this, not sure if all the different ISA has it, I believe they don?t actually, they like removing instructions, just to save a few transistors, as result you can?t trust its there, and if its not there then shift rotating is faster. (As exceptions are slow)

It does but things like GCC built in byte swaps can't use it because they use direct values. Would need a pointer macro to do it. x86 has the best of both worlds. However, all PPC should support the reversing codes, but not all PPC support endian mode switching.

Assembler is not generic code, maybe why its often ends up being macro junk insted.

Assembler can also be needed when C codes is optimised out. I tried many times to do a direct jump to a function with an exact address from C and GCC always wiped it out and kept making relative jumps or something. Likely an easy way of doing it but I got sick of trying to crack so just wrote some ASM which worked.

Union and struct combo is really fast to handle 32bit code, not used often, but 16bit RGB is tricky, I found 16bit lookup tables handy, removes a lot of masking, shifting, etc.

Wondered if union would help myself. But still not easy to turn pointer into function that reverses bytes. At least on C++ still don't think you could define an endian swap class to drop in place of a pointer.

 Status: Offline
Profile     Report this post  
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 11-Aug-2021 7:14:35
#144 ]
Elite Member
Joined: 6-May-2007
Posts: 10308
From: Greensborough, Australia


That little trapCode() function would use the following stats then. PPC: 23 instructions, 92 bytes 68k: 12 instructions, 32 bytes The 68k uses less than half the instructions and has nearly 1/3 of the code size while the code is much easier to read. Why did Motorola think PPC could replace the 68k for embedded markets again?

They must have got sucked into the AIM alliance. And then tried to make up for it with the ColdFire 68K abomination, another CPU that misses out on 68K features. What they should have done, is what they were doing, jump on the RISC bandwagon with the 88K follow up instead of abandoning it. Well, perhaps.

I always wondered why all programs didn't get a pointer to ExecBase passed in at startup like interrupt handlers. The code isn't any longer on the 68k for using absolute short addressing to access address $4 and in the beginning was no slower as any access was from chip memory. When fast memory was added to Amigas, it was faster to access a cached value in fast memory rather than in chip memory. The zero page was later remapped to fast memory with the MMU on some Amigas so both accesses are equally fast again but it is still faster for all Amigas to cache the address in fast memory.

Standardising this in the ABI would have helped. A0 and D0 were used for args and argl. This is analogous to to argv and argc, meaning arg string and arg length in my case. So pre-loading ExecBase to A6 made sense.

move.l lr,r8

Here is 68k format now. If I had my way, I would make the 'e' in "move" optional on the 68k though.

Actually, it depends on the assembler format, I discovered 68K can be written as "mov" along with different conventions for things like indirect addressing.

But, unlike 68K, the order on PPC is backwards. With destination before source. The operands are in backwards x86 order.

x86 needed more optimization or at least it had more opportunities for optimization. Yes, the best compiler technology did evolve from supporting the x86 architecture and all other architectures were at a disadvantage. PPC received pretty good compiler support at one time but I expect support is already starting to diminish. Like the 68k, compiler support is unlikely to disappear altogether but often so called newer compiler technology has not been able to surpass GCC 2.95.3 code generation which was just starting to get good. Newer compilers do more work often to produce inferior code.

That tends to be the the bench mark. Been a long time since. But like AHIv4 nothing since appears to have matched it.

If all Trevor wants is the fastest Amiga play toy he can buy, then indeed a POWER Amiga would give it to him while wasting a lot of parallel processing potential and having no future as POWER went even bigger and more expensive in the latest generation. The A1222 was clearly aimed at the lower end of the Amiga market to boost users and development but it looks like the price and compatibility will fall short of the goal if it ever comes out. He is making the same mistake as Motorola did trying to replace the 68k with PPC in the low end embedded market. It is pretty clear what Amiga customers want for the low end which is the 68k and Amiga chipset compatibility. Low end PPC hardware has been disappointing customers for decades.

The POWER machine should have more future than the current pick of the crop, since unlike the current crop, you can still buy it and have it configured like a desktop. But wasted power is a result of a means to an end. The end is to bring a decent OS4 machine to the users with high price and POWER is the best I've seen that is able to do it. Besides, it can still run Linux fully, and likely one already able to boot it unlike the custom kernels needed now without a full installer. Wasted power becomes a side effect. Right now, POWER9 users are out there, criticising the X5000 as a joke. When POWER users are hanging crap on other PowerPC people, in an x86 world, you know it's bad.

What stalled the A1222 was the esoteric CPU chosen. If I was at the planning meeting that day I would have said no to a rare PPC chip rarer than PPC itself. One that is now extinct in PPC land.

But, low end Amiga customers have no interest in PPC and OS4. In fact MOS can be run on cheaper hardware. Or a more expensive X5000. The A1222 did get interest from it's lower pricing point, even from the 68K crowd. And the A1222 would easily be faster than the fastest 68K Amiga.

 Status: Offline
Profile     Report this post  
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Aug-2021 13:16:08
#145 ]
Elite Member
Joined: 6-May-2007
Posts: 10308
From: Greensborough, Australia


I apologise, I am not really into AOS 4 ABI, but rather than "virtual 68K registers", or the double indirection of a struct->funtion(struct, args), what's preventing a base + displacement call on the PowerPC, like the exec of old ? Are you aware of any specific reason ?

In simple terms, the PPC doesn't have any kind of JSR call that can do the base + displacement. Like most operations on PPC, it must be done manually, with a few instructions in line. In this case loading the function pointer into a register, then moving it to a callable register and finally calling it from the register. So neither calling from a base offset nor loading an address into the function register is possible.

However, branches can be done directly, as per normal. Likely that branching would be used internally in the OS like it did on 68K. Libraries are small enough and even the whole Kickstart code could be cross branched if it was in one block of memory.

And in the "struct->funtion(struct, args)" case, that's what 68K had to do as well, since the base had to be loaded into the base register and called off it.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 was originally founded by David Doyle