@Birbo
Quote:

Can you explain how the work together with Hyperion is organized? Or is the developement of the Exec totally seperate from the rest of developement of Amiga OS 4.1?

There is a steering committee consisting of Timothy, Trevor and myself which oversees which direction things are going. Other than that, ExecSG development is separate.

_________________
ExecSG Team Lead

@ssolie

Quote:

ssolie wrote: @Lou Quote: What are the odds of back-porting to 68k? What are the odds of the port everyone and their mother wants (ARM)? I can certainly say everything is on the table again. But let's focus on the immediate future which means X5000 and A1222. I believe there was a promise to have AmigaOS 4.2 on the X1000 as well unless Hyperion has changed its mind. So we already have plenty to do.

I like Pi

_________________

@Jose

Quote:

But aren't the cores accessing the protected areas the only ones that need to be trapped ? And each core has it's own MMU that can trap it, so I missing why you say there would need to be MMU trap + Inter processor interrupt broadcast + semaphore overheads. I know nothing about MMUs other than what they generally do but I think the PPC MMU would be the same. There would probably be some overhead when launching processes due to setting up the other MMUs for the traps.

If just disabling task-switching was the goal there would be no problem even in a SMP system: the task-switch code for each processor could just check if the system allowed switching and continue running their assigned task if not. Forbid() is used as a lock ensuring there will be no interference from other tasks: for the Amiga with one processor it meant just making sure there will be no (preemptive) task-switch before Permit() is called (or used as a macro), for a multiprocessor system that will not be enough as for n processors/cores there are up to n tasks running at the same time with n-1 tasks that can potentially interfere.
So calling Forbid() on one processor need to disable all other tasks on other cores from running until they are Permit()ted again. That isn't too hard to do actually but not especially efficient, the task calling Forbid() sends hardware interrupts to all other cores and waits until they have entered the interrupt handler before returning. The interrupted cores are allowed to continue after the main one call Permit().

The delay for Forbid() plus Permit() would be:
Send interrupts to other cores
Wait until other cores are waiting on a lock
+
Signal other cores to continue

Supporting the macros means additional complexity to handle MMU exceptions which brings the delay to:
MMU exception for Forbid()
Send interrupts to other cores
Wait until other cores are in their interrupt handler and waiting on a lock
-> Delay for the slowest interrupt response + spinlock
Return from exception handler
+
MMU exception for Permit()
Signal other cores to continue running (spinlock release - low cost)
Return from exception handler

In response to possible ports to other ISAa

I would wait a year or two as I think there'll be attractive RISC-V targets. I would use that time to make a little endian version of the OS + incorporate much needed improvements like memory protection, 64 bits and the like.

_________________

@WolfToTheMoon

Wait to see if the Tabor arrives / sells as to whether there is any market left to support an ISA change. We don't have enough PPC / new NG / updated 68k software as it is but we will have even less after an ISA change. My brain tells me only Vampire, emulation and AROS will survive the complete death of PPC.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

And Morphos on x86.

_________________

@BigD

I'm not sure that Tabor was a good idea.

Still... Switching to a little endian PPC should be considered since it would make porting a lot easier in some cases(like the JIT engine on Odyssey etc). And when and if they switch to a different ISA(all popular ISAs today are LE) it will make life easier for everyone.

_________________

@Argo

Quote:

I like Pi

Yeah. The Broadcom BCM2711B0 SoC would make a great entry-level Amiga. Add SATA, a Texas Instruments PCM5122 DAC, and a nice desktop case with an internal power supply. That would be hard to beat for the price.

@WolfToTheMoon

Quote:

I would wait a year or two as I think there'll be attractive RISC-V targets.

RISC-V looks promising.

I've not yet given up on PPC, now that it has been open sourced. PPC is still used in the embedded market, and if someone comes out with a PPC SoC with a GPU, that could work well for Amiga. It's not likely to happen, but it could.

The problem with PPC is that there's nothing in the middle: it's either embedded SoCs or really high-end server/workstation parts. I feel pretty confident saying that PPC on the desktop is permanently dead.

@BigD

Quote:

My brain tells me only Vampire, emulation and AROS will survive the complete death of PPC.

If that's what it comes down to, then we'll make the best of it.

@coldacid

Quote:

Honestly, it might be easier and more worthwhile to take the Dragonfly BSD kernel, hack UAE into it for legacy apps, and build a whole new OS on top of that similar to Apple building OSX on top of Mach+NeXT, than to try and hack memory safety into Exec.

OK, I can't resist commenting on this, since I already have this big post going.

Something good could be build on top of DragonFly, but by most objective measures Linux would be better. It has more drivers, better software support (e.g. Netflix), and more architectures (ARMv8, POWER and RISC-V). It is also more modular. It could be tricky trying to separate the DragonFly kernel from the rest of the system, whereas with Linux you add components to it rather trying to take them apart.

DragonFly has a certain sentimental appeal because of Matthew Dillon's past Amiga history, but that only goes so far.

Last edited by bison on 03-Nov-2019 at 04:31 PM.
Last edited by bison on 03-Nov-2019 at 04:17 PM.
Last edited by bison on 03-Nov-2019 at 04:11 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@WolfToTheMoon

But that will break all support for 680x0 and PowerPC programs we have...

Maybe we should work on getting Javascript JIT and the other stuff working...
i think that be easier. (it only takes a lot of time )

However what might be cool if it was possible to run little and big endian programs on the same system, I'm sure there some issues to work out, but that might be more doable. (You might need different SDK to do that.)

Last edited by NutsAboutAmiga on 03-Nov-2019 at 04:08 PM.
Last edited by NutsAboutAmiga on 03-Nov-2019 at 04:07 PM.

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

@NutsAboutAmiga

A break needs to happen anyway.... There are perfectly acceptable emulators that could run 68K code and the more used PPC programs are likely to be still maintained so a recompile shouldn't be too hard.

_________________

@Megol
I think the biggest problem is that there were programs using Forbid() for stuff that should've never been used for and the OS has no means to distinguish when it's really needed to stop all multitasking (including other cores) and when it's actually not needed...
But anyway, one day when/if I have time I'll look into AROS sources and experiment, just to smash my brain a bit...

_________________

José

@BigD
"Wait to see if the Tabor arrives / sells as to whether there is any market left to support an ISA change."

There's no way Tabor sales are a measure of the market, it's too outdated/underpowered, even by old NG standards! I for one would be interested in a Power9 solution, which costs as much as a X5000 and would be vastly superior. The Tabor was a terrible idea. Yes, I know they're totally different sub niches (high vs low end), but the Tabor is eating resources that could be used for stuff that matters.

Last edited by Jose on 03-Nov-2019 at 04:30 PM.

_________________

José

@Jose

Yep that's the real problem! But a compatible system can't assume things and have to accept the worst case scenario - a program stopping concurrent tasks with a write to a certain memory location.

One way to mostly keep compatibility could be to tag all program files/drivers conforming to a new standard as safe with other programs/drivers restricted to run in a sandbox. That would still have a lot of problems though...

Quote:

Argo wrote: @ssolie Quote: ssolie wrote: @Lou [quote]What are the odds of back-porting to 68k? What are the odds of the port everyone and their mother wants (ARM)? I can certainly say everything is on the table again. But let's focus on the immediate future which means X5000 and A1222. I believe there was a promise to have AmigaOS 4.2 on the X1000 as well unless Hyperion has changed its mind. So we already have plenty to do.

I like Pi
[/quote]

Who doesn't love Pi?

Looking forward to the Schultz PiRos release...

Little endian version is extremely stupid idea.
It is obvious that breaking compatybility should be used to solve problems, no to add new one.
After breaking compatybility aos should be open source, endian agnostic, should have memory protection, unix compatybility and good quality drivers.
This means no exec, no dos, just amiga gui (MUI) and graphics on top of unix.

So now there are two ExecSG kernels. How does this work for end user? You buy Hyperion OS4 then swap in AEON ExecSG or what?

@AmeegaGuy

Quote:

So now there are two ExecSG kernels. How does this work for end user? You buy Hyperion OS4 then swap in AEON ExecSG or what?

You didn't see any of the AmiWest-videos on youtube, do you?

There is of course only one ExecSG-kernel (owned by Trevor, licensed to Hyperion) and Hyperion and the ExecSG-team work together on AmigaOS4.

Last edited by AP on 03-Nov-2019 at 06:42 PM.

_________________
AmigaOne X5000/40, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD

@bison

Quote:

I've not yet given up on PPC, now that it has been open sourced. PPC is still used in the embedded market, and if someone comes out with a PPC SoC with a GPU, that could work well for Amiga. It's not likely to happen, but it could. The problem with PPC is that there's nothing in the middle: it's either embedded SoCs or really high-end server/workstation parts. I feel pretty confident saying that PPC on the desktop is permanently dead.

Oh, that's a high fast ball; I can't resist a swing. Hope I don't miss...

Amiga has such a long history with (a) custom chips, and (b) PowerPC, that I'd see this as an opportunity, rather than an obstacle. There's no need to make the best of cheap embedded SoC's or high-end server chips. Just as MiniMig and Apollo Team have engineered an Amiga on an FPGA, a dedicated team could (in theory) engineer a desktop-class PPC -- starting on FPGA perhaps, then implementing in ASIC -- specifically for the Amiga market. After all, PowerPC is now an open spec.

The real question is, what's left of the Amiga market, and would people be willing to pay the price? I was talking about this with an embedded engineer (my father) and he said that the problem with putting, e.g., Vampire into ASIC is that you need millions of dollars to get the fabs going. I don't think that Vampire has enough chance of scaling beyond the Amiga retro market to make such a bid worthwhile, and I haven't seen anyone talk seriously about Vampire-on-ASIC in a while (but I haven't been following either). But a general-purpose desktop- or mobile-class PowerPC run by a company with a vested interest in keeping it alive would be a good possibility. ARM has shown that a company with a single-minded focus on a product can not come from out of nowhere to dominate certain markets: cell phones, Raspberry Pi, etc.

PowerPC's designers and marketers were for decades uninterested in the desktop; to them, it was more a nuisance than a market. Motorola/Freescale/NXP dominated the embedded business, and IBM's entire business model is based on high-profit enterprise service. They made stuff for Apple as long as they thought it worth their while, but eventually Freescale decided embedded customers were more important than Apple (hard to argue), and then Apple decided IBM's timeline wasn't sufficient for them, and once they were out, that was it.

Perhaps the various Amiga camps could agree on a PowerPC CPU design suitable for the desktop, and put into production something that would be of interest beyond merely the Amiga.

If I'm going to dream, I might as well dream big, n'est-ce pas?

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@simplex

The combined PPC Amiga market and resources of the companies involved is not nearly sufficient enough to design a bespoke PPC CPU.

However, now that the PPC is completely open, we might see someone getting in with a new PPC CPU.

I'm not counting on it since RISC-V is on a roll right now and I don't see a market for a new PPC core - hard to beat IBM at their own game and on the lower end of the spectrum ARM and RISC-V have either wiped out or are in the process of completely replacing PPC CPUs.

The best target for a small niche OS right now(or in a year or two) is RISC-V, IMHO.

Staying on PPC means relying on ancient snd slow Freescale CPUs(which will be becoming rarer and rarer and more expensive) or going to POWER systems which means no sub 1500 EUR motherboards in the foreseeable future.

_________________

@WolfToTheMoon

Quote:

Staying on PPC means relying on ancient snd slow Freescale CPUs(which will be becoming rarer and rarer and more expensive)...

Wow! That's the best marketing for the Tabor I've ever seen ; Buy the Tabor because we'll never see its like again

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios