@kamelito

(continued)

Moving forward, and what should have happened in OS4, restrict 68K (i.e. legacy) software to a common (shared) memory area and require new (PPC, etc.) applications to have a private, virtualized address space. Legacy message passing could be done via the shared (68K) memory space, and new software via an updated/improved/new set of APIs which allow processes to allocate or register memory as shared - between processes or globally, or somewhere in between.

All of this would require a fundamentally new Exec. The MMU would manage accesses to memory, as with modern operating systems. Map the 68K legacy environment into the first N MBs of memory, and mark it as read-only for processes running on any core other than core 0. Memory barriers would be issued for any message passing (i.e. memory transactions).

I would say, for heaven's sake, take the (seemingly abandoned) AtheOS / Syllable Desktop and see if you can get the author's permission to use it under some acceptable licence. It was originally envisioned as a replacement for AmigaOS, after all - and it's got everything you need for SMP, MP, Posix, x86, etc. I've not used it, but it certainly looks feature complete, albeit 32 bit only at present.

Last edited by Snorg on 30-Oct-2019 at 11:25 PM.
Last edited by Snorg on 30-Oct-2019 at 10:05 PM.
Last edited by Snorg on 30-Oct-2019 at 10:03 PM.
Last edited by Snorg on 30-Oct-2019 at 09:45 PM.

@ssolie

I'd like to know if new exec will have standard SMP just like windows/linux os or a simpler AMP design, where extra cpus could be managed as async coprocessors.

A nice example, even if quite different, could be CELL cpu where SPEs are used as fast async coprocessors.

Thank you.

Last edited by Fl@sh on 31-Oct-2019 at 04:48 PM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Fl@sh

Yes to the latter. Apart from the SMP/AMP distinction, he touched upon essentially that at the show (the Saturday joint Q+A with Trevor Dickinson, as I recall). I suppose this would be something like grand central dispatch, and that would definitely be an improvement but it is, in my opinion, a dead end (but maybe that doesn't matter right now).

Last edited by Snorg on 30-Oct-2019 at 11:00 PM.

@Snorg

Good points.

@ssolie

your thoughts vs post #41
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=43487&start=40&post_id=828548&order=0&viewmode=flat&pid=828544&forum=2#828541
?

I would like to see long term plan.
How can AOS become "modern".


I would like to see progress to true new/third generation with "state of the art" solutions, rather than using resources put into half-kludge multicore (+63bit+memhalfprotect) implementation.


IMO: it would be ok to need to use dual booting between vanilla execSG and execTG AOS, as needed, untill third generation is mature enough for all daily needs.

Last edited by KimmoK on 31-Oct-2019 at 07:19 AM.
Last edited by KimmoK on 31-Oct-2019 at 07:18 AM.
Last edited by KimmoK on 31-Oct-2019 at 07:13 AM.
Last edited by KimmoK on 31-Oct-2019 at 07:13 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@ssolie

I'm wondering if you are coming back to answer the rest of the questons.

@Snorg

The problem have never been the unprotected single address space design, there is no problem adding multiprocessing to such a system if there is no other limitation. Amiga OS have several other limitations that make multiprocessing with backwards compatibility hard or impossible.

For instance (looking at 68k) there were originally a lack of proper synchronization primitives in the kernel which meant Forbid() and Disable() were used for synchronization, supporting those in a multiprocessor design is very hard as they aren't just system calls but also supported as macros. This means writing a memory address can stop multitasking, standard hardware can't trap this write as it requires a conditional but immediate stalling of all other processors upon writing some values. There are several other problems making it even harder.
(I've proposed a method for FPGA processors but even that isn't too likely to work)

Multiprocessor support could work using a legacy sandbox which of course Hyperion didn't want and in some ways designed out from their system. It would be much work especially now when all PPC components need to be part of that sandbox...

@megol

Everything you say is true, and yes having a single address space is not strictly the problem; the problem is all of the things it allowed you to do (and were done) that thwart precisely what is being discussed.

As you have pointed out, there are a number of reasons why the entirety of the 68K - OS, applications, etc. - needs to be 'virtualized' in some fashion.

Really, if there is to be meaningful progress and a future for the platform, it needs a new foundation, one that captures the strengths of AmigaOS, and lets go of the rest.

I don't think anyone is genuinely expecting a radical departure from the past at this point, but surely we can accept what is obvious.

Is there even such a need to have support for Forbid() and Disable() ? I remember the Libraries book IIRC discouraging their use and advising to use Semaphores instead. And this was even in the 2.x times. So what you guys are suggesting is that developers disregarded that and continued to use it ? I once thought maybe with some creative usage of the MMU Forbid() and Disable() could continue to be used but I never bothered to look further as to why that hasn't been suggested. And if it hasn't it's probably not possible...

_________________

José

@bennymee

Quote:

Is there anything new in the RadeonHD drivers

Yes, some work is currently being done on the RadeonHD front. The latest code commit is dated 25 October.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Jose

Note If I am misremembering any of the following, I welcome correction. Briefly:

Consider the purpose of Forbid(), Permit(), Enable(), and Disable(). Essentially, they make a set of operations atomic - i.e. to execute as a 'transaction'. Ideally, such transactions are initiated and completed by the OS in order to ensure correct behaviour should the underlying hardware or software change.

The former two function as a kind of mutual exclusion mechanism by preventing the OS from switching tasks for everything between the two calls. If you were accessing or modifying some shared data (in particular lists), you needed some guarantee that it was not going to be modified "out from underneath you", or something could/would be guaranteed to go (very) wrong.

Disable() and Enable() prevent and enable interrupts, and therefore preclude execution of interrupt service routines that might likewise cause problems - with the side effect of temporararily preventing task switching as well.

Note: I've made three minor edits to the following paragraph in the interests of accuracy.

Although it was more efficient to use macros instead of OS calls, the unfortunate result is the situation we have: *for any* macros *that* expand to inline(d) machine (68K) instructions instead of OS calls, *there is thus* no way to 'intercept' and properly handle these transactions in, for instance, multi-processing environments - that is, unless you are emulating or (JIT) translating the 68K code and have incorporated some mechanism to compensate for those instructions - certainly easier said than done.

The practical alternative (perhaps) is to use an existing solution for legacy (think UAE), and side-step the issue altogether. The overarching question remains - what strategy to modernize the OS?

Last edited by Snorg on 02-Nov-2019 at 12:36 AM.
Last edited by Snorg on 31-Oct-2019 at 11:12 PM.

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. Legacy and current AmigaOS pretty much requires memory insecurity to function at all, that bird has flown.

@Snorg

Yeah, I remember what they did, so basically we're trying to avoid the same thing as in the normal AmigaOS multitasking context, the difference is that with multiple cores those functions don't work anymore and would have to be modified.
You're implying that if OS calls were used for Forbid() etc., it would be possible to solve the problem. If that is true (I don't know...), then I don't get what is all the fuss about. The macros that are used instead of Forbid() etc. could simply be patched manually. They correspond to very tiny instruction sequences and the same way that a huge library of WHDLoad installed/modded games exists (with much more modifications than this would require), the programs that we're interested in could be modded. Those that were not yet modified could be "forbidden" by the MMU to write to a memory space (if the user decided to run them anyway), to avoid messing other apps. IIRC think parts of the system are already protected by the MMU in OS4, but not sure if it's able to protect rogue programs from writing to lists, if it is, the problem would only be in the program potentially reading corrupt information, which is acceptable, they just wouldn't work, without major harm to the system.
Just thinking off the top of my head, strange time for me to think about this, but hey I'm bored :)

_________________

José

@ssolie

Hi Steven Solie

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?

Thanks

_________________
Sometimes we give people a lot of credit just because they’re writing nice sentences even if it isn’t adding up to much.

@Hypex

That's why I asked - a poor attempt at humour, "Is this thing on?" - that is to ask the same thing.

I know there are great demands on people's time, but 'you guys' are really dropping the ball here: people are disgusted with the silence, lack of transparency, and infighting. Having some PR is, potentially, a very good thing - just follow through and keep communication lines open.

Mr Solie seems like a nice guy, and I wish him and his colleagues only the very best, but he initiated the conversation, here - finally.

"Let's keep this party going!"

I only hear crickets.

@Snorg

Quote:

I only hear crickets.

There's nothing to say is there? See you in Q2 2020 and pray that they meet their software and hardware goals leading up to it. In the mean time most of us already have hardware to enjoy. If you've got money burning a hole in your pocket buy a Vampire and / or Stephen Jones' Checkmate 1500 Plus case. If not enjoy your Classic!

Nothing else to say really. I'm glad that they're still attempting a release despite the delay, mobo respin and the court case!

Last edited by BigD on 01-Nov-2019 at 04:12 PM.

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

@Jose

Only supporting semaphores would mean only supporting new software. That could have been a solution but at the time multiprocessor systems were unusual even for expensive workstations so I doubt the compatibility penalty was worth it.

As I wrote the problem is that Forbid() must immediately halt all other processors and doing it with standard hardware is AFAIK impossible as only the processor accessing the protected area will trap. Perhaps one could handle that with the trapped processor interrupting all other processors making them wait on a semaphore. Overheads would be great though: at least MMU trap + Inter processor Interrupt broadcast + semaphore overheads.

In FPGA the overheads would be much lower and wouldn't need MMU traps, OTOH FPGA softcores are extremely slow compared to mainstream high performance processors.

@Snorg

Quote:

Snorg wrote: @Hypex I know there are great demands on people's time, but 'you guys' are really dropping the ball here: people are disgusted with the silence, lack of transparency, and infighting. Having some PR is, potentially, a very good thing - just follow through and keep communication lines open.

You question the 'silence, lack of transparency' after there is video of an event just last weekend where they talked about ExecSG, and on a thread where extra questions are requested to clarify anything people dont understand?

Do you know how entitled this sounds?

_________________

@thread

It is not true to say that there are macros for Forbid(), Permit(), Disable() and Enable(), expanding to inline code. These are all Exec calls and must go through the Exec's library vectors to be actioned.

This was true in the 68k days and is still true in PPC-land.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@Derfs

Touche, but you do sound somewhat judgmental yourself.

In any case, no, I'm not presuming anything:

1) There was a request for questions and several questions remain outstanding - as others have pointed out,
2) yes, there was good video coverage for a community event - with information which, as others have pointed out, was extremely light on substance, particularly given the unfortunate blog entry situation had stirred up some anticipation, and
3) yes, great, credit where it is due - absolutely, but I've been referring to an ongoing situation of silence and now there has been an invitation for feedback (correction: for questions) - should we all collectively shout accolades and praise, or expect meaningful information?
4) and lastly, my comments (although perhaps not clearly enough) relate to those parties who have undermined the community/market, not to those who are trying to do something positive for it.

I have not directed criticism at any one person. I don't presume to speak on any other's behalf - yes, I have had a bit of a short fuse lately, but what is wrong with "follow through and keep the communication lines open?" Perhaps it could have been worded as a request, but I'm not the only one who is less than patient with the status quo, am I?

One event alone does not change much, so no, I don't know why you would accuse me of sounding entitled. In reponse, I should say, there's something about trust being earned.

So if you are trying to defend anyone because my comments seem out of line, you have not grasped my intention. and you are directing your criticism at the wrong party.

Last edited by Snorg on 02-Nov-2019 at 01:22 AM.
Last edited by Snorg on 02-Nov-2019 at 01:01 AM.
Last edited by Snorg on 02-Nov-2019 at 12:19 AM.
Last edited by Snorg on 01-Nov-2019 at 11:42 PM.

@tonyw

Sure, and thanks. I do recall, however, conversations about macros vs calls in this context (and relating to the comments by megol) and I presumed at the time those regarded enabling and disabling interrupts on the part of user mode code. As I said, I'm an outsider looking in, so maybe someone can share the particulars, if anyone is interested.