Many have brought up that question and if you now look at mschulz plans for AROS other than Pi version. These versions will not be compatible but be amiga like in some ways.
I guess you heard about BEOS and from that the Haiku project. I tried many times to boot it and when it work it felt very half finished. Long time since I tried it but to me AROS is more what I like and more mature. That is in many ways thanks to ports from Amiga classic and MorphOS.
There are of cause possible to fork AROS and try to turn it to something more mothern. Some tried in the past but nothing came out it. At least that is something I could belive in. Starting something new is a job so huge that without a workforce of hundreds we talking decades before it can turn out to something usefull.
Last edited by nikosidis on 30-Aug-2018 at 04:17 PM. Last edited by nikosidis on 30-Aug-2018 at 04:14 PM.
megol wrote: Or Commodore could just have inserted semaphores and discouraged the use of the macros when launching the Amiga 3000. By then it should be obvious there could be a market for a multi-processor Amiga IMHO.
The RKRM Libraries does discourage the use of the Forbid, Permit, Disable and Enable macros. I believe the ExecBase TDNestCnt and IDNestCnt counters are needed per core as well as other information which is probably best handled with an ExecBase structure per core (I expect AROS is doing this but I haven't checked). I don't believe it would be necessary to obtain a semaphore lock with a per core ExecBase structure. A 68k counter increment/decrement instruction would remain atomic on the current core where with RISC it becomes 3-5 instructions (lock, load, inc/dec, store, unlock). The macros would still be a problem as the next instruction can't execute until the other cores stop executing. This practically requires an exception without custom hardware and would be interesting at that (snoop a memory location and turn on/off other cores on certain values). The macros could be replaced by a trap instruction or similar which would do similar actions as the functions (the functions could use the same trap).
Quote:
However when it comes to AROS on non-68k systems (and perhaps even those) is really that level of compatibility a requirement?
I hope "that level of [68k] compatibility" is not required as we don't know if it is possible yet on the Raspberry Pi. Michal hasn't said anything about finding a way to enable big endian support without using a deprecated instruction. A compatibility breaking little endian AROS ARM port for the Raspberry Pi probably makes more sense otherwise. Big endian hardware is a dying breed and 68k compatibility is much less efficient without it.
9 crawler(s) on-line.
102 guest(s) on-line.
1 member(s) on-line.
nikosidis 
