Re:AROS SMP
The experimental SMP on x86_64 is being ported to the big endian mode of ARM7 on RasPi 2 and 3. Why not ditch PPC and discuss fixing bugs in AROS?

@Signal
Your multiprocessing system isn't what's normally considered multiprocessing (it of course _is_ one). I wouldn't be surprised if my current computer have 80 cores more or less specialized when counting the CPU with 8 cores, the GPU with 50+ cores (depending on how one count them), the WiFi, Ethernet, SSD, HDD, fan and power controller (+ a lot more). But in the end if people ask how many processors this system have I'd reply 8, not 80.

The path to a multiprocessor Amiga is clear: sandbox plus redesign.

@Samurai_Crow

That makes eminent sense, with the caveat that PPC remains central to Morphos and Hyperion OS.

If I may say, Morphos was AmigaOS NG. It would have been an excellent foundation upon which to build AmigaOS 5, but unless something dramatic happens, there will be no AmigaOS 5.

As for OS 4, PPC support could have been a conduit to extending the API for proper memory and process isolation, and for new (then PPC) applications to use modern conventions, particularly the use of protected, shared memory for IPC. But that wasn't done, in no small part because the (original) goal was to get an updated, ported OS in the hands of waiting customers on a short schedule. Fine, but the result is we do not have a proper foundation to build upon - technically, commercially, or otherwise.

Tangentially, while I applaud and appreciate the efforts of A-EON to create new hardware I, for one, cannot possibly justify the cost. Believe me I hate to say it, but cost is a prohibitive factor that has been pointed out by others time and again.

AROS is a way forward for the community in the form of a hobbyist OS. Still, I hope the Morphos team delivers a port to x64 (and Aarch64, ideally) but, without core improvements (memory protection in particular - necessitating a modern replacement of the ABox), I fail to see how it can advance (i.e. grow) the platform.

Last edited by Snorg on 30-Mar-2019 at 03:25 AM.

AROS SMP support is still experimental, and it breaks compatibility with the existing applications.

As I've already said on the other thread, the easy and more realistic multicore path for existing Amiga applications on current Amiga-/like o.ses is to embrace AMP.

So, one core where to bound all existing applications. And all cores where to spread the new AMP tasks.

How about AMP for the 32-bit backward compatibility environment and full SMP for the compatibility breaking 64-bit host environment. Then we just have to figure out what the host environment will be like.

@Samurai_Crow: either going to SMP or 64-bit already breaks compatibility.

It means that you need to run two o.ses, the 32-bit legacy one and new SMP and/or 74-bit one, in parallel. Which means isolated each other (maybe with some resource sharing).

Whereas I think that the goal/aim of some people was/is to have both legacy and "multicore" apps to co-exists.

@cdimauro

AROS already supports hosted operations on top of another OS. It runs like a user-mode app on top of Linux and others already. The host OS doesn't even have to be compatible which is the point I was trying to make.

@Samurai_Crow: but I think that people here likes to have an Amiga-/like o.s. even for the host.

@cdimauro

AROS will soon have both bases covered. The 64-bit compatibility breaker for RockPro64 with SMP and a hosted 32-bit 68K JIT running AROS 68k.

@Signal

Quote:

Signal wrote: It has been mentioned before that the original Amiga was implemented as a multi-processor system.

That's a misunderstanding.

There is only one part in the custom chips that could move data by itself, it's called copper and it is totally restricted in it's kind of commands or it's way of system access. All other parts in the Amiga chipset are only specialised DMA engine.

I would not call the Amiga a multi processor system, in comparison with the Amiga every C64 with a floppy is a multiprocessor system with an additional full sized 6502 in the floppy. And in comparison with the Amiga, this 6502 subsystem could be used for standard calculations.

A multi processor system usually uses many CPU cores (or processors) where every CPU is acting as standard processor with full system access and full command set.

@Thread

Before starting a discussion I would recommend to read the definition of the term you are talking about.
https://en.wikipedia.org/wiki/Multiprocessing

Last edited by OneTimer1 on 31-Mar-2019 at 10:20 AM.
Last edited by OneTimer1 on 31-Mar-2019 at 10:14 AM.

@OneTimer1
Had to call the topic something(?). Your suggestion would be?

You stated Quote:

A multi processor system usually uses many CPU cores (or processors) where every CPU is acting as standard processor with full system access and full command set.

I agree each core is a standard processor, but does each processor require a full command set?
Full system access would not be required if that processor were dedicated to, lets say, graphics. It would be up to other processes to send graphics data to the 'graphics processor' with the highest priority one over riding whatever task is running.

This may be done with flags, interrupts, or thread priority on a multi thread CPU.

It's just a discussion. Not a plan.

_________________
Tinkering with computers.

@Signal

What your talking about is something that can only do a fixed thing, but can't be used for another. A relatively complex, lets you have CPU that only can do Word, and one CPU that can only do Excel, just to put in that framework, I think problem with that is that is complex design, not able to leverage the CPU's power for another task. Generally that’s bad design. Also you have problem of having source code, you need to adapt to work in nonstandard framework.

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

@NutsAboutAmiga

there was a plan for this in the very past by commedore. but it was not multicore but multiply cpu's
http://www.bigbookofamigahardware.com/bboah/product.aspx?id=224

and this is what i think is the latest wee have herd with smp for os 4.x
http://blog.hyperion-entertainment.com/?p=1184

@NutsAboutAmiga
At this time AOS can only use one processor regardless of how many are on the chip or in the computer. So lets say that for a 2 core CPU all graphics data is handled by the second CPU before being routed to the graphics card. If the second CPU is able to keep one or two screens of data in its RAM buffer with a second or third thread streaming the data to the card it could be possible to get around DMA. Or use DMA with the CPU selecting which screen to display.

Of course this can't be done. Not standard.

_________________
Tinkering with computers.

@megol

Quote:

The path to a multiprocessor Amiga is clear: sandbox plus redesign.

I don't see the point either - apart from perhaps the academic exercise.

The few actively supported applications that would take advantage of core legacy OS upgrades could be updated to take advantage of the features in the redesign.

@ne_one

let's say you like have stack enlargement and memory protection and so on, the legacy application won't work inside a modern box, they need to work in legacy box.

Quote:

The few actively supported applications that would take advantage of core legacy OS upgrades could be updated to take advantage of the features in the redesign.

So the legacy apps like TurboCalc, ImageFX, PerfectPaint, BlitzBasic can't be recompiled for a new design, as they are 680x0 programs, and source code is not available.

There is also some advantages to old design like low latency. so maybe it nice to keep it.

Last edited by NutsAboutAmiga on 31-Mar-2019 at 07:12 PM.

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

@NutsAboutAmiga

Quote:

So the legacy apps like TurboCalc, ImageFX, PerfectPaint, BlitzBasic can't recompiled for new design, as they are 680x0 programs, and source code is not available.

Quote:

A-EON Technology Ltd is pleased to announce that it has purchased the source code and development rights for ImageFX

Source

#6

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

@number6

ok, replace that with TvPaint then...

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

@Samurai_Crow Quote:

Samurai_Crow wrote: @cdimauro AROS will soon have both bases covered. The 64-bit compatibility breaker for RockPro64 with SMP and a hosted 32-bit 68K JIT running AROS 68k.

True. But let's see how many data-crunching applications can/will be ported to AROS SMP.


@OneTimer1 Quote:

OneTimer1 wrote: @Signal Quote: Signal wrote: It has been mentioned before that the original Amiga was implemented as a multi-processor system. That's a misunderstanding. There is only one part in the custom chips that could move data by itself, it's called copper and it is totally restricted in it's kind of commands or it's way of system access. All other parts in the Amiga chipset are only specialised DMA engine. I would not call the Amiga a multi processor system, in comparison with the Amiga every C64 with a floppy is a multiprocessor system with an additional full sized 6502 in the floppy. And in comparison with the Amiga, this 6502 subsystem could be used for standard calculations. A multi processor system usually uses many CPU cores (or processors) where every CPU is acting as standard processor with full system access and full command set. @Thread Before starting a discussion I would recommend to read the definition of the term you are talking about. https://en.wikipedia.org/wiki/Multiprocessing

According to your link, even Amiga was a multiprocessing system:

"a multiprocessor is a computer system having two or more processing units (multiple processors) each sharing main memory and peripherals, in order to simultaneously process programs.[3][4] A 2009 textbook defined multiprocessor system similarly, but noting that the processors may share "some or all of the system’s memory and I/O facilities"; it also gave tightly coupled system as a synonymous term."


@retro Quote:

retro wrote: @NutsAboutAmiga there was a plan for this in the very past by commedore. but it was not multicore but multiply cpu's http://www.bigbookofamigahardware.com/bboah/product.aspx?id=224

"This is a not-expected-to-function prototype"
Quote:

and this is what i think is the latest wee have herd with smp for os 4.x http://blog.hyperion-entertainment.com/?p=1184

According to the "Where are we now ?", this is what should be still missing:

"the balancing will be introduced, which then finalizes the first implementation of SMP support in AmigaOS"

It means that you can introduce even the stupidest and simplest load balancer, and you have a working OS4 SMP system!

Do you believe that in 4 (FOUR) years they had no time to implement it, and finally give SMP to their customers (which are waiting from MORE THAN 4 years)?


@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @ne_one let's say you like have stack enlargement and memory protection and so on, the legacy application won't work inside a modern box, they need to work in legacy box.

Exactly. And MP is enough to have an almost new o.s. which RESEMBLES the Amiga o.s., because the current one and its applications are fundamentally based AND work thanks to the LACK of MP.
Quote:

Quote: The few actively supported applications that would take advantage of core legacy OS upgrades could be updated to take advantage of the features in the redesign. So the legacy apps like TurboCalc, ImageFX, PerfectPaint, BlitzBasic can't be recompiled for a new design, as they are 680x0 programs, and source code is not available.

Some applications will NOT take advantage from multicore. BlitzBasic, for example, is a single core/process application.

Unless BlitzBasic applications start using multicore by themselves, but this is a different thing.

TurboCalc is another one where it's difficult to take advantage of multicore. It will require A LOT of work to sync (lock, mutex, whatever is needed) concurrent recalculations.
Quote:

There is also some advantages to old design like low latency. so maybe it nice to keep it.

Low latency with the current CPU monsters is a less sensible argument.

@Signal

Buster was a bus bridge, translating the 68k bus protocol to the Zorro2 bus protocol. Super/Fat Buster translated the 68k bus protocol to Zorro3 bus protocol.
While there was some bus arbitration logic involved to make sure Zorro cards and the CPU do not collide with each other on the bus, Buster is not a processor nor is it in charge of multiprocessing.

Would something outside of a multicore CPU not be slower than something inside that multicore CPU?
If you are talking about making use of multiple cores such as in t2080, t4240 type CPUs, then you want that to be part of the software loader and scheduler in the OS kernel, which is software... Load it into memory for the CPU it is scheduled to run on, considering CPU cache for the intended core, perhaps choosing memory address on the closest of multiple memory busses, etc.

_________________
All glory to the Hypnotoad!