@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?

Watch the Amiwest videos... It's in there.

_________________
All glory to the Hypnotoad!

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

I'm sure there will be screams of blasphemy but I too can't possibly imagine investing limited resources into retrofitting things like SMP into a rickety foundation.

The academic exercise may prove to be interesting and it may help justify purchases of the A5000 and A1222 but it's really a solution looking for a problem.

There are countless other areas that need to be addressed and investing in the past is going to prevent the platform from moving forward.

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

I think there's a lot of merit to that idea, but... that's a subject for a another thread.

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

@tonyw
Quote:

tonyw wrote: @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.

That's lovely in theory. Unfortunately, the NDK3.9, as (still) available from H&P has the following assembler macro for DISABLE:

DISABLE     MACRO   ; [scratchReg],[NOFETCH] or have ExecBase in A6.
            IFC     '\1',''             ;Case 1: Assume A6=ExecBase
              MOVE.W  #$04000,_intena   ;(NOT IF_SETCLR)+IF_INTEN
              ADDQ.B  #1,IDNestCnt(A6)
              MEXIT
            ENDC
(...)

FORBID      MACRO   ; [scratchReg],[NOFETCH] or ExecBase in A6!
            IFC     '\1',''             ;Case 1: Assume A6=ExecBase
              ADDQ.B  #1,TDNestCnt(A6)
              MEXIT
            ENDC
(...)

**      $VER: ables.i 39.0 (15.10.1991)

Stuff like Forbid/Permit/Disable/Enable even as macros are no problem at all if you start one AOS instance per (big) app. Think about it in similar way as starting two UAEs. In one you run "Final Writer". In the other you run "Directory Opus". They are completely isolated, can do forbid/permit/macro/whatever. Can crash themselves or the(ir) OS. It will not affect the program in the other UAE. And when they crash, they would max. crash their OS instance (UAE) but not the other. And OS instances can run on different cores.

Comparision with UAE is only to show isolation similarities with such approach. It does not mean approach would inherit slowness or startup slowness or resource hungryness of UAE.

An AOS (instance) by itself does not take up basically any resources or cpu time. If you have a single big app (no other stuff like Workbench) running in AOS waiting for user input on a slow PC (if AOS was x86 native and AOS app was ported as native x86 app) then it would be maybe eating 0.01 % cpu time of the single core it is running on. Because there's not much else then timer ticks going through input.device/input handler/intuition happening. You could probably have 1000s of AOS instances running at the same time and still nowhere near reach 100 % cpu load.

With something like this you would have memory protection between (big) apps, resource tracking, multiple core (not full/real SMP) for free with no speed loss, without change of APIS (forbid/permit, access to OS structures: no problem).

@Georg

Quote:

stuff like Forbid/Permit/Disable/Enable even as macros are no problem at all if you start one AOS instance per (big) app.

I think the programs that used this macros are already broken, you can't break anything that is already broken , it clear we need a new NDK3.1.4 / NDK3.2 that includes fixes for stupid stuff like this. So that people who is working on stuff on mc680x0 can compile safely there programs without having to worry about things like this.

I come more and more to the conclusion that sandboxing might be the best decision for AmigaOS.
1. You most do it anyway when going 64bit.
2. It allows you remove linked lists and stupid stuff like that from the host kernel.
3. You can schedule task in background, without making changes to the core OS.
4. You move critical stuff out of harm's way, (console, disk, keyboard, rs232), some thing like debug console might be useful think action replay iii.

Last edited by NutsAboutAmiga on 02-Nov-2019 at 11:43 AM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 10:16 AM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 10:04 AM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 10:03 AM.

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

@umisef

Thanks, Bernie. I wasn't aware of the assembler macros. I simply looked up the library function vectors.

_________________
cheers
tony

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

@mr2

I am still present, and still coding.
My "real life" has put additional demands on my time, so I'm not as productive as I once was.

I'm not working on RadeonAudio at the moment. I don't know if someone else has picked it up.

I am still working in Audio drivers, and I am still looking forward to leaving drivers behind and getting back to Score.

When any of this reaches "complete" is not at all predictable.

Thanks,
Lyle

_________________
question=(2b||!(2b))

Having done some programming in 680x0 assembler for Amiga computers, I never understood why anyone would want to use the assembler macros for shared library calls when it's so simple to just do:

move.l SysBase(pc),a6
jsr _LVOForbid(a6)

If anything, using them just leads to more inefficient code as the library base register is needlessly reloaded from memory.

@Snorg

Quote:

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

And likewise. "Have you tried turning it off and on again?"

Quote:

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.

Yes that was the underlying purpose but in their case they took it to an extreme. One disables multitasking and the other disables interrupts. The first will freeze the system interface but the other will completely freeze the system. Allowing simple user programs such power just looks like a bad idea. That's a really trustworthy OS.

If data needs atomic access that's what semaphores are for. I use them in my own programs. But, internally they forbid multitasking.

Quote:

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

I would say there is. All they do, at their core, is increase a byte counter in ExecBase. The macros would do the same as Exec does internally. So, I really didn't see why there needed to be ASM macros. Just to save a JSR call before temporarily freezing the system.

Though I liked the idea of each 68K application being an own task, I agree ExecBase needs to be isolated away from 68K. Now is the time. In fact, OS4 software should have no need to touch ExecBase either, and they shouldn't need too. But, a legacy ExecBase created for 68K would help here, that is only used for classic programs.

Last edited by Hypex on 02-Nov-2019 at 02:18 PM.

@Georg

"Stuff like Forbid/Permit/Disable/Enable even as macros are no problem at all if you start one AOS instance per (big) app. "

Or one per core, but I suspect there are practical advantages in delegating legacy to one core.

Anyway, I'd like to say thanks to all who posted their insights here. I wish I were optimistic, but I'll move on now - as my wife says, opening your mouth just gets you in trouble.

@lylehaze

Ah, ok. Thanks for the info. I hope you can finish the boring staff and have fun with Score again.

_________________
Sam440ep-flex 800MHz 1GB RAM R9250 128MB SB Live!

@megol
"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."

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.

_________________

José

@Jose

No it can't be just trapped, beside when should you release control of that data?

Also when working with trap handlers you have the same problem, if try change trap handler and put your code there, how can be sure that trap handler is not over written, by different program before you can trigger the trap.

Also I'm skeptical about the suggestion of using ques, becomes if let's say insert some code from program A, into list or que, there is chance that program A, as quit'ed before code is executed, the nice code also gone by the time que is executed.

Also when you dream up alternatives to MUTEX or SHAMPORES or SPINLOCKS and so on you will have issue when porting over software, you can't use the MUTEX locks because this what is the standard, on all operating systems.

Last edited by NutsAboutAmiga on 02-Nov-2019 at 06:13 PM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 06:11 PM.

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

@mr2
Quote:

Quote: I prefer to stay lock step with Hyperion on releases. Any idea about a payment for such releases? I would gladly pay if they bring some new features.

I try to stay out of the money side of things myself so I don't know what the decision is on that front.

_________________
ExecSG Team Lead

@Gregor
Quote:

What is the latest U-Boot version for X5000/20?...

U-Boot has been a concern of mine for a long time. Now that we have ExecSG under control, I think reaching back into the firmware is a logical step. With that in mind, I want to see if we can arrange something with A-EON in regards to firmware so that a) everybody is on the same version and b) we can update it as needed. It only makes sense.

Sorry I don't have any specifics. I'm more concerned about who controls it at this point.

_________________
ExecSG Team Lead

@Petah
Quote:

Percentage-wise, how much work on the drivers and other software exclusive to the A1222 Tabor is completed and how much remains to be done?

I don't see much point in doing percentages. Programmers always tell you they are 90% complete. What I do know is we have an ISO now so full system testing has resumed. In short, I don't see product shipping until next year at this point.

Quote:

Are any major hurdles concerning the remaining work on the A1222 Tabor software expected to show up, or will the final stretch be more about smooth sailing and less about obscure, hard-to-find bugs?

There are certainly a couple of show stoppers left to fix for sure. It won't be smooth sailing and never is.

_________________
ExecSG Team Lead

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

_________________
ExecSG Team Lead

@kamelito
Quote:

How did Microsoft managed to be very compatible with all previous versions of Windows (even before win95) and be able to have true SMP/memory protection and so on, why it is not possible on Amiga? This mean that technical solutions exist right?

Money. It also helped to have a world wide monopoly.

_________________
ExecSG Team Lead

@Fl@sh
Quote:

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.

In order to retrain backwards compatibility some sort of hybrid solution is most likely.

_________________
ExecSG Team Lead