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

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
21 crawler(s) on-line.
 39 guest(s) on-line.
 2 member(s) on-line.


 MEGA_RJ_MICAL,  Hammer

You are an anonymous user.
Register Now!
 Hammer:  14 secs ago
 MEGA_RJ_MICAL:  1 min ago
 matthey:  1 hr 24 mins ago
 Gunnar:  1 hr 29 mins ago
 DiscreetFX:  1 hr 55 mins ago
 agami:  3 hrs 44 mins ago
 OlafS25:  3 hrs 56 mins ago
 eliyahu:  4 hrs 38 mins ago
 NutsAboutAmiga:  4 hrs 39 mins ago
 Marcian:  5 hrs 45 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 Next Page )
PosterThread
NutsAboutAmiga 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 8-Jul-2021 12:41:58
#121 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12791
From: Norway

@Rose

are you sure?

Number of user who use computer for more then playing games, is maybe not so high.

https://aminet.net/statistics

Number of uploads per year is the same as 2009
I think some stuff uploaded in 1993-1998 was maybe before the internet. High peeks are maybe not so correct.

Last edited by NutsAboutAmiga on 08-Jul-2021 at 01:18 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 01:14 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 12:55 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 12:47 PM.

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

 Status: Offline
Profile     Report this post  
number6 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 8-Jul-2021 13:46:49
#122 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11540
From: In the village

@NutsAboutAmiga

Quote:
Yes, page has only 6043 users, where some margin hare inactive accounts


AW member activity is not = active users.

Nevertheless, we used to consider members logging in at least once in the past month to be considered "active". You could also argue merely "interested". Also consider a member does not need be logged into AW in order to read most of the site.

Having just checked that number, it happens to be 304 approximately, depending on length of month. btw, this # is fairly consistent (unchanged) since last I checked.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

 Status: Offline
Profile     Report this post  
Hypex 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 8-Jul-2021 15:28:24
#123 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@thinkchip

Quote:
I think they should discontinue backward compatibility of OS4.x. It is holding it back. That would make it a lot like a new operating system.


I think it's too late for that. They needed that at the start. Although since the original intent was to port OS3 68K into OS4 PPC that's understandable. But it has caused problems holding it back and trying to work around legacy functions. The direct message passing was quick way of working but now slower passing by reference is the way. However, AmigaOS needs to migrate to indirect handles, the use of direct pointers can be rather unsafe and locks resources in memory is something crashes.

I really don't see why such a big deal was made with running 68K as close as possible. They broke fine working 68K functions in PPC which makes no sense with intergrating it. 68K is emulated no matter what so I see no need to copy all old functions then complain down the track it holds the OS back. A 68K wrapper for native functions would have been fine. I like the idea of each 68K process being a PPC process but I think in retrospect they should have shared a 68K sandbox API to separate 68K and PPC.

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 8-Jul-2021 17:39:11
#124 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12791
From: Norway

@Hypex

Quote:
passing by reference is the way.


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.

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.

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.



Last edited by NutsAboutAmiga on 08-Jul-2021 at 08:05 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 06:04 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 06:03 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 05:59 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 05:48 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 05:46 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 05:44 PM.
Last edited by NutsAboutAmiga on 08-Jul-2021 at 05:39 PM.

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

 Status: Offline
Profile     Report this post  
OldFart 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 8-Jul-2021 19:23:17
#125 ]
Elite Member
Joined: 12-Sep-2004
Posts: 3059
From: Stad; en d'r is moar ain stad en da's Stad. Makkelk zat!

@number6

Quote:
Also consider a member does not need be logged into AW in order to read most of the site.

Yeah, I'm one of them!

Following this thread and my conclusion (as often before) is: opinion exceeds knowledge and a lot of wishfull thinking.

OldFart

(Just logged in for this posting. Back into lurking mode!)

_________________
More then three levels of indigestion and you're scroomed!

 Status: Offline
Profile     Report this post  
kolla 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 8-Jul-2021 21:31:22
#126 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2852
From: Trondheim, Norway

I have somewhere between 6 to 10 68k Amiga systems I switch between quite regularly (and quite a few more that are in various degrees of “dorment”) - how do you count that market wise?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
Hammer 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 9-Jul-2021 4:40:50
#127 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5235
From: Australia

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@Rose

Yes, page has only 6043 users, where some margin hare inactive accounts.

Anyway there Spanish and French web pages as well, they never come here due to the language barrier, there AmigaOS4.x user that never come here because of all fighting in comments. There also other pages like EAB that also where popular places, with users that never come here. How many of this user that have at one time registered a user account here I do not know. There some exotic Swedish pages, and popular germen pages. but combined amount active Amiga users are more 1000 I’m pretty sure.

FYI, CommodoreAmiga Facebook group has 25.6K members.

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

 Status: Online!
Profile     Report this post  
MEGA_RJ_MICAL 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 9-Jul-2021 6:12:52
#128 ]
Super Member
Joined: 13-Dec-2019
Posts: 1200
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

Quote:
FYI, CommodoreAmiga Facebook group has 25.6K members.


Friend Hammer,
you really, really, really are into useless number, aren't you?

It means NOTHING, it's people who at some point in their life had an Amiga, and in a moment of nostalgy searched "amiga" on that cancerous dump of wasted time and narcissism, found the group, and tapped the like button.

21th century pavlovism.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

 Status: Online!
Profile     Report this post  
agami 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 9-Jul-2021 7:14:18
#129 ]
Super Member
Joined: 30-Jun-2008
Posts: 1632
From: Melbourne, Australia

@number6

Quote:
AW member activity is not = active users

I agree.
I'm a good example: I check AW.net about 4-5 times a week. I turn on an Amiga some 10-15 times a year. Averaging about once per month.
I wouldn't consider myself an "active" user.
I do however consider myself as a likely purchaser of new developments in the Amiga space; Those that represent good value for money of course.

I question whether there are actually any truly "active" Amiga users out there. As @NutsAboutAmiga indicated: it's a software thing.
There are a handful of those that have stated in the past that their Amiga NG system is their primary computer for daily tasks. How true that is today is hard to gauge. I know that for the work I do, the software is just not there for AmigaOS 4.x or MorphOS. Hell, it's not quite there on Linux so every now an then I have to go to macOS or fire up a Windows VM on the Linux box.

So I'm with @Rose on this one: 1,000 truly active users would be an excellent start.

_________________
All the way, with 68k

 Status: Offline
Profile     Report this post  
kolla 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 9-Jul-2021 7:33:45
#130 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2852
From: Trondheim, Norway

I hereby announce Amiga kOS 54 code name "Kitty Kallen", because Little Things Mean a Lot. Two more weeks, when it's done.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
tlosm 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 9-Jul-2021 12:05:58
#131 ]
Elite Member
Joined: 28-Jul-2012
Posts: 2746
From: Amiga land

@kolla



@all

... if i have to use a new "amiga like os" different from classic or os4 there are one good alternative Morphos and Aros too...

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

... forgot to write and if they made a miracle a super new os , ultra cool and with 64bit an 3D and with jit and so so .... i will never use it ... just because #nomoreAeoninmyhome

Last edited by tlosm on 09-Jul-2021 at 12:09 PM.
Last edited by tlosm on 09-Jul-2021 at 12:09 PM.
Last edited by tlosm on 09-Jul-2021 at 12:08 PM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

 Status: Offline
Profile     Report this post  
Hypex 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 10-Jul-2021 15:56:19
#132 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@matthey

Quote:
Assuming *ctx is in a0, *SysBase is in a1 and DebugPrintF() is an external function in a library with its two arguments in registers a0 and a1.


Just about. In this case DebugPrintF() is an Exec function. Code looks fine.

Quote:
Even on the 68k it is better to avoid accessing location $4 as much as possible. In the trapCode function we have it passed in as an argument which is nice.


Yes, I wondered why it was common to read from $4 a lot. I can understand for the ROM routine but nothing else needed to read it, as the OS should have passed it. The OS4 interrupt handler passes ExecBase along.

Quote:
PPC has the overhead of setting up the stack frame for every function accessing the stack so there are no small functions. It is better to do lots of inlining but this reduces code sharing and makes the code more difficult to read especially on lower optimization levels when trying to debug the code. This program was likely compiled at a lower optimization level as trapCode() is not inlined in main().


Yes, but so does the 68K. Simple for 68000 but on 68040 the stack frame is slightly more complicated, at least in an interrupt like we are dealing with here. It would be default optimisation. However, unlike the 68K, the PPC doesn't really have a stack. Nothing is stacked automatically on a function call. It goes into the link register LR. Good for fast functions, bad for recursion. The code has to manually setup a stack frame. With more optimisation the frame can be optimised out. Also PPC can't do indirect jumps like on 68K, it has to load the address into a register first.

Quote:
However, the DebugPrintF() may be inlined into trapCode() judging from the size of trapCode() which defeats the purpose of the example of a "jump to subroutine" in an Amiga shared library and an Amiga shared library call normally can't be inlined. We could look closer at the PPC code to see. Let's start at the beginning.


Well, it would have a bit of overhead there, since it has to run a typical PrintF() routine and then send text over serial. The SetTaskTrap() in main() will be called in a similar way.

Quote:
This could have been allowed to be written like the following.

mov r8,lr


Ouch. x86 format.

Quote:
Not much thought was put into PPC assembler because compilers were going to be so great that assembler would be obsolete. Sophisticated RISC compilers were the secret weapon to win the battle against CISC but it backfired when x86-64 programmers were able to use assembler to optimize their code (despite it being more difficult to read than 68k assembler) while PPC programmers didn't know what was going on under the hood. In fact, where are the PPC assembler programmers to interpret this code for us?


It also backfired when PPC compilers were crap compared to all the effort put into x86 compilers. Lots of code can do better but GCC can produce some undesirable output. Endian conversion routines can be the worst. A problem is PPC can do it fine in memory which is where it is usually stored. But a PPC routine has registered parameters. Strangely, with the emphasis on doing everything in registers, PPC looses out here as it had no byte swapping instructions unlike a 80486. And Core can do BE R/W direct on memory. So the best thing to do, if the compiler knows what's going on, is to pass pointer and swap indirectly if that works. I can interpret PPC code but it never looks easy to read. You need to read PPC code if you need to understand an OS4 crashlog.

Quote:
The A1222 is likely the last PPC hardware if it ever comes out. For the low end Amiga market, A 68k SoC ASIC on a SBC would be more compatible and cheaper than an A1222 or Sam460. For the higher end desktop market, an architecture change is needed but then I don't see a way to make a profit so goodbye A-Eon.


Thee A1222 was a good idea and got lots of interest. Unfortunately it was poorly executed I think. The PPC chosen was EOL and more incompatible with a G4 than an AMCC was with a G4 including its esoteric FPU design. I'm sure emulating FPU on SPE was a great proof of concept but I can only imagine the cost wasted on writing an emulator. The problem with PPC is there are only these slow embedded designs available. It's lost out to ARM or there would have been affordable PPC boards by now.

The Sam is the most popular. The X1000 seems to be left behind. And at the top end the X5000 gets the love. But, you read blogs and even Power people think the X5000 is a joke. I tend to agree. Just port OS4 to Power9 and be done with it. The board is already there. Don't need special firmware, just hack the firmware on it like they hacked CFE on the X1000. The time and money spent producing slow boards five years too late and still porting OS4 to it could be better spent on decent hardware. I can't even load up Drive in Firefox in Linux running two cores on my X1000. Odyssey would run rings around it on a single core on Power 9!

Last edited by Hypex on 11-Jul-2021 at 03:54 PM.
Last edited by Hypex on 10-Jul-2021 at 04:15 PM.
Last edited by Hypex on 10-Jul-2021 at 04:13 PM.

 Status: Offline
Profile     Report this post  
Hypex 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 10-Jul-2021 16:19:25
#133 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@kolla

Quote:
Am I the only one who think Studio 54?


No, I thought of it as well. The music industry doesn't like copy cats and simlar sounding melodys. Will AmigaKit get out of this one?

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 10-Jul-2021 16:20:47
#134 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12791
From: Norway

@Hypex

Quote:
But a PPC routine has registered parameters.


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

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

So no push/pops, no stack on powerpc as you know it from the good old days.
Anyway push and pops are also kind of indirect addressing, growing or shrinking from its base address.

Quote:
PPC looses out here as it had no byte swapping instructions unlike a 80486


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)

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

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.

Last edited by NutsAboutAmiga on 11-Jul-2021 at 10:56 AM.
Last edited by NutsAboutAmiga on 11-Jul-2021 at 10:54 AM.
Last edited by NutsAboutAmiga on 11-Jul-2021 at 10:53 AM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 09:14 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 09:13 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:57 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:56 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:55 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:51 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:51 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:49 PM.
Last edited by NutsAboutAmiga on 10-Jul-2021 at 04:48 PM.

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

 Status: Offline
Profile     Report this post  
Hammer 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 10-Jul-2021 23:13:07
#135 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5235
From: Australia

@MEGA_RJ_MICAL

Quote:

MEGA_RJ_MICAL wrote:
Quote:
FYI, CommodoreAmiga Facebook group has 25.6K members.


Friend Hammer,
you really, really, really are into useless number, aren't you?

It means NOTHING, it's people who at some point in their life had an Amiga, and in a moment of nostalgy searched "amiga" on that cancerous dump of wasted time and narcissism, found the group, and tapped the like button.

21th century pavlovism.

There are 6038 individuals who expressed an interest for Vampire 68 K-based FPGA accelerators and there's another group with Terrible Fire, ACA, and Wicher series accelerators.

AmigaOS 3.1.4 sales indicate good retro sales for Hyperion.

Your argument is useless.

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

 Status: Online!
Profile     Report this post  
matthey 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Jul-2021 0:53:16
#136 ]
Super Member
Joined: 14-Mar-2007
Posts: 1965
From: Kansas

Hypex Quote:

Just about. In this case DebugPrintF() is an Exec function. Code looks fine.


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?

Hypex Quote:

Yes, I wondered why it was common to read from $4 a lot. I can understand for the ROM routine but nothing else needed to read it, as the OS should have passed it. The OS4 interrupt handler passes ExecBase along.


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.

Hypex Quote:

Yes, but so does the 68K. Simple for 68000 but on 68040 the stack frame is slightly more complicated, at least in an interrupt like we are dealing with here. It would be default optimisation. However, unlike the 68K, the PPC doesn't really have a stack. Nothing is stacked automatically on a function call. It goes into the link register LR. Good for fast functions, bad for recursion. The code has to manually setup a stack frame. With more optimisation the frame can be optimised out. Also PPC can't do indirect jumps like on 68K, it has to load the address into a register first.


The stack frames on PPC are stacked at least and r1 is considered the stack (frame) pointer as I already pointed out. All references to the current stack frame are relative to r1. There is no push/pop auto increment or decrement functionality. Note that other architectures can handle stack frames in a similar way by subtracting from the stack pointer to allocate space and adding to it to deallocate space (most stacks grow down to lower addresses). The PPC eliminated some hardware functionality which increased code size and reduced readability.

Hypex Quote:

Ouch. x86 format.


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.

Hypex Quote:

It also backfired when PPC compilers were crap compared to all the effort put into x86 compilers. Lots of code can do better but GCC can produce some undesirable output. Endian conversion routines can be the worst. A problem is PPC can do it fine in memory which is where it is usually stored. But a PPC routine has registered parameters. Strangely, with the emphasis on doing everything in registers, PPC looses out here as it had no byte swapping instructions unlike a 80486. And Core can do BE R/W direct on memory. So the best thing to do, if the compiler knows what's going on, is to pass pointer and swap indirectly if that works. I can interpret PPC code but it never looks easy to read. You need to read PPC code if you need to understand an OS4 crashlog.


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.

Hypex Quote:

The A1222 was a good idea and got lots of interest. Unfortunately it was poorly executed I think. The PPC chosen was EOL and more incompatible with a G4 than an AMCC was with a G4 including its esoteric FPU design. I'm sure emulating FPU on SPE was a great proof of concept but I can only imagine the cost wasted on writing an emulator. The problem with PPC is there are only these slow embedded designs available. It's lost out to ARM or there would have been affordable PPC boards by now.

The Sam is the most popular. The X1000 seems to be left behind. And at the top end the X5000 gets the love. But, you read blogs and even Power people think the X5000 is a joke. I tend to agree. Just port OS4 to Power9 and be done with it. The board is already there. Don't need special firmware, just hack the firmware on it like they hacked CFE on the X1000. The time and money spent producing slow boards five years too late and still porting OS4 to it could be better spent on decent hardware. I can't even load up Drive in Firefox in Linux running two cores on my X1000. Odyssey would run rings around it on a single core on Power 9!


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.

Last edited by matthey on 12-Jul-2021 at 01:01 AM.

 Status: Offline
Profile     Report this post  
retro 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Jul-2021 15:30:24
#137 ]
Super Member
Joined: 16-Dec-2003
Posts: 1049
From: Unknown

any screenshots of this new thing

 Status: Offline
Profile     Report this post  
FairBoy 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Jul-2021 16:21:22
#138 ]
Member
Joined: 8-Jun-2020
Posts: 76
From: Unknown

@retro
there's no "new thing". It's just blown up speculation started by amiga-news.de 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  
davidf215 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 12-Jul-2021 21:54:56
#139 ]
Member
Joined: 14-Feb-2010
Posts: 95
From: Texas

@tlosm

Quote:
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  
Hypex 
Re: A-EON is internally testing Alpha releases of their own operating system
Posted on 13-Jul-2021 16:42:17
#140 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@NutsAboutAmiga

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 Next Page )

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