@cdimauro

Quote:

But it's perfectly legal on the Amiga o.s.: this is the main problem.

I don't think this matters. A PowerPC program should never touch IDNestCnt or TDNestCnt directly. There are proper functions for that.

And if a 68K program touches them directly it is using old code and shouldn't be used anymore. Some macros wrote to INTENA, IIRC, or some hardware address. But how much of the software we use would do this? Indeed, what software would need to disable multitasking or interrupts, that we still like to use on AmigaOS4?

@Hypex

It is easy making "AmigaOS" SMP capable by killing compatibility - but then it isn't an Amiga anymore.

It is in fact trivial to make an Exec clone with SMP support, that isn't the problem. Compatibility is.

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: cdimauro wrote: But it's perfectly legal on the Amiga o.s.: this is the main problem. Programs can be recompiled, and or forbidden to run, it should be no harder then checking for version string. And its also possible to check CRC/SIZE/Name and ban applications that is not safe, and is possible to force a GrimReapir when a program do some that was allowed but is not any more, forcing PPC program to follow stricter guidelines should not be problem.

Of course, you can do it, and solve the problem of the SMP implementation with the usual black list.
Quote:

Most PPC programs are ported from Linux, there are some unique applications like TuneNet, that might not be recompiled, but TuneNet can easily be replaced if some was willing, the plugin and codecs can be recompiled.

Is there a list of native PowerPC applications? Ported applications aren't interesting, since you can find them on other o.ses.
Quote:

The main problem will be to keep supporting 680x0 program as OS gets updated. But I'm sure many things can de supported and setting pointer so they trigger exceptions when some one tries to write or read from this, the exception handlers that can take care of what ever was expected by applications, the only question is how mutch effort should be done

For 68K apps, the emulator / JIT has to provided atomicity of RMW instructions, like itix already described.
Quote:

to support support workarounds for poorly coded applications.

Such applications can be legal if they did what the guidelines allowed them to do. I don't call them "poorly written": the fault was done by who have written such guidelines...

Quote:

Hypex wrote: @cdimauro Quote: But it's perfectly legal on the Amiga o.s.: this is the main problem. I don't think this matters. A PowerPC program should never touch IDNestCnt or TDNestCnt directly. There are proper functions for that.

The question for me is simple, boolean: either an application is allowed to touch these fields by the formal guidelines, or not. In the first case, they are legal; in the second case, no.
Quote:

And if a 68K program touches them directly it is using old code and shouldn't be used anymore. Some macros wrote to INTENA, IIRC, or some hardware address. But how much of the software we use would do this? Indeed, what software would need to disable multitasking or interrupts, that we still like to use on AmigaOS4?

I've no idea, but if the 68K apps argument is so much common and repeats time by time, maybe those apps are still used whatever is their behavior.

So the problem of running them on an SMP-capable Amiga/-like o.s. is still actual and live. And megol is right here.

@cdimauro

Quote:

Is there a list of native PowerPC applications? Ported applications aren't interesting, since you can find them on other o.ses.

If you don't like Linux, but like some applications or games you like then way should you boot any other OS. Besides ported applications are rewritten to take advantage of AmigaOS features like Arexx, datatypes, iconify and other stuff, you do not have on other operating systems.

Quote:

For 68K apps, the emulator / JIT has to provided atomicity of RMW instructions, like itix already described.

That not true, well coded application will use API's like permit() and forbid(), or shampores to make sure read and writes is serialized when they need to.

Quote:

Such applications can be legal if they did what the guidelines allowed them to do. I don't call them "poorly written": the fault was done by who have written such guidelines...

If a developer try invent there own ways to implement thread safety when OS provides good functions to make reads and writes tread safe, then I see its fault of the programmer not the OS.

Anyhow if programmer does not know how to write system friendly code then I bet programs are not that worth running anyway, besides there are other options to running poorly written 680x0 programs like EUAE.

Quote:

The question for me is simple, boolean: either an application is allowed to touch these fields by the formal guidelines, or not. In the first case, they are legal; in the second case, no.

poking system structures has been discouraged for a long time back.

http://archive.org/stream/International_Amiga_Developers_Conference_Notes_1993_Commodore/International_Amiga_Developers_Conference_Notes_1993_Commodore_djvu.txt

Read the notes about pokeing and peeking at system structures. Developers who do not follow the guide lines, are playing roulette, hoping system structure are not going to get changed.

This is what the Commodore says about it:

"
Remember that system structures are subject to change or extension. For new graphics
hardware, structures likely to be extended are those associated with ColorMaps, ViewPortExtras, Sprites, and many others. To deal with changing system structures, developers should use system calls to allocate, create, and manipulate these structures.

Many new "Get" and "Set" calls have been added to graphics.library to provide an upwards-compatible mechanism for reading and setting structure members which were previously accessed by program code either directly or through macros which accessed them directly. For future compatibility, do not directly access or change any structure or value for which a "Get" and "Set" call is available. And do not declare or AllocMem any structure for which a special allocation call is provided.
"

Hyperion has given warning like this one, and I bet Hagge&Partner has too.

Last edited by NutsAboutAmiga on 26-Aug-2014 at 11:43 PM.

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

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: Is there a list of native PowerPC applications? Ported applications aren't interesting, since you can find them on other o.ses. If you don't like Linux, but like some applications or games you like then way should you boot any other OS. Besides ported applications are rewritten to take advantage of AmigaOS features like Arexx, datatypes, iconify and other stuff, you do not have on other operating systems.

I doubt that all ported applications are so much well integrated with the Amiga/-like o.s..

Anyway, they aren't so important like the native ones, which are missing in other o.ses. There should be the native ones which drive the Amiga/-like o.s. usage IMO.
Quote:

Quote: For 68K apps, the emulator / JIT has to provided atomicity of RMW instructions, like itix already described. That not true, well coded application will use API's like permit() and forbid(), or shampores to make sure read and writes is serialized when they need to.

Well coded apps can use also the macro provided by Commodore and that directly accesses some critical fields of the o.s..
Quote:

Quote: Such applications can be legal if they did what the guidelines allowed them to do. I don't call them "poorly written": the fault was done by who have written such guidelines... If a developer try invent there own ways to implement thread safety when OS provides good functions to make reads and writes tread safe, then I see its fault of the programmer not the OS.

See above: Commodore also gave macros to access critical o.s. fields. And that was maybe for speed: a single instruction to disable multitasking or interrupts is much faster than a system call.
Quote:

Anyhow if programmer does not know how to write system friendly code then I bet programs are not that worth running anyway, besides there are other options to running poorly written 680x0 programs like EUAE.

Sure. But if you want to change the o.s. to introduce new features while keeping compatibilities, you have to deal with applications that correctly followed the guidelines and may not work in any case.
Quote:

Quote: The question for me is simple, boolean: either an application is allowed to touch these fields by the formal guidelines, or not. In the first case, they are legal; in the second case, no. poking system structures has been discouraged for a long time back. http://archive.org/stream/International_Amiga_Developers_Conference_Notes_1993_Commodore/International_Amiga_Developers_Conference_Notes_1993_Commodore_djvu.txt Read the notes about pokeing and peeking at system structures. Developers who do not follow the guide lines, are playing roulette, hoping system structure are not going to get changed. This is what the Commodore says about it: " Remember that system structures are subject to change or extension. For new graphics hardware, structures likely to be extended are those associated with ColorMaps, ViewPortExtras, Sprites, and many others. To deal with changing system structures, developers should use system calls to allocate, create, and manipulate these structures. Many new "Get" and "Set" calls have been added to graphics.library to provide an upwards-compatible mechanism for reading and setting structure members which were previously accessed by program code either directly or through macros which accessed them directly. For future compatibility, do not directly access or change any structure or value for which a "Get" and "Set" call is available. And do not declare or AllocMem any structure for which a special allocation call is provided. " Hyperion has given warning like this one, and I bet Hagge&Partner has too.

That was only for graphic, because of the upcoming new chipsets. If you read the whole document, you'll find nothing about other o.s. parts, except the support for the, new, CPUs and how to deal with their cache and the DMA.

So, directly accessing to IDNestCnt, for example, was still valid, and apps that did it perfectly legal / good / well coded/ not poorly written...

Last but not least, you're talking about 1993. How much software was written before this, and that followed the previous guidelines?

@Olegil:

But all of the information discussed so far is pointing out that it is plain outright possible and actually a good thing.

a single-cpu system IS sync-locked based on the CPU mechanisms for cache and memory access,

@All:

In the case of a multi-processor system (even the A1000 with Blitter qualifies as this),
the solution is to run each "processor" with a fixated memory resource subset from the common unified memory map.

Any "Additional 68K" as an example... would require that there is an SMP controller present,
and this would act as a "hardware semaphore" and a pre-requisite would be some kind of "memory mapping" of the data-structures at risk for core-exec as a common element.
(reading execbase would be easy yet writing would need to be lock-delayed on access)

Certain things like Interrupts would then be handled by the SMP chip which then can trigger the master processor to handle them or round-robin interrupts between processors.

I would choose for the boot processor to also handle interrupts,
double the "scheduler quantum"(how much time on a processor is allocated for a given tasks slice of time to run on the processor) and deliberately set a round-robin between processors at the original quantum time (this can be acheived by hooking the call for switching tasks, and counting a loop of processors as to which processor runs the next ready task off the list) sync-locking access by disabling SMP for the duration of execbase write operations (AllocMem/AllocVec/FreeMem/FreeVec/...) restoring it once the protected routine is exited.

Also I would deliberately map ExecBase and other "critical" system structures as "non-cacheable" memory regions (this is already a capability built into the 030 and later 68K systems)

This would avoid multi-writes considering SMP is disabled for the critical memory locations *in*hardware* and the SMP would be through the CPUcard Memory Controller (ExecBase is allocated into this region as part of bootstrap)

this side-steps and pushes local writes from devices and the CPUs into a single-path without cache issues.

Please note I am discussing a *combination* of both an FPGA in the CPUslot between the CPU and motherboard for SMP support *AND* patching Exec (wholesale replacement of the Exec Library using an alternate library IS possible as well) for specific routines also.

In Addition to the above only *8* bytes of memory require to be considered volatile when adding an additional 68K processor to a physical CPU card and the rest is subject to implimentation details (the location 0 and location 4 of physical memory without VBR or other considerations).
Along with the VBR of the Boot processor relocating its zeropage (access to this for interrupts or other system details would require management for non-boot processors)

In any case an "E68K"(Emulated 68K) only requires that"atomic" instructions have atomic-locking instructions as part of the routine for the instruction that needs this (this would be host specific and void the issue of the native scheduler breaking the atomic-locking conditions).

Accordingly... pre-allocation of assigned resources is one of the safest means of setting up threaded/shared-task/multi-process environments as only the assigned task has access to its own resources and given a "protected"(read as safety enabled) means of using a shared memory area or allocating and assigning memory as "shared" to a target as a message would be limited by practical.

given the above there is nothing stopping any of the 68K or PPC systems we currently have of being fully SMP capable (but there does remain a heavy burden requirement for the design and implimentation of an Amiga-like OS to retain a unified memory layout or limit use of virtualized memory as "shared" from a fixed address so that there is no "collision" of access to the region virtualized being on-top of the same memory as another allocation.

so the problem is not a simple matter of "sync-lock" but the view of memory from each device.

And the current OS implimentations in the "Amiga" family ALL appear to retain a unified memory model with limitations on virtual memory options as "Allocation requires Shared markings or it is not able to be shared".

It is more than adequate for a round-robin of processors to occur underneath the round-robin of the 68K Exec (this doubles the quantum time per-process on a 2 processor system in addition to the prerequisite sync-lock on entry to exec.library routines)

I would personally look at a custom library being implimented that relocates its own LibBase into a protected memory with FPGA "gate controller" that has special SMP support for sync-locking and enable/disable of processors as part of a CPU card design.

This "custom smp library" would then provide its own address at location $4 and retain the original AbsExecBase content internally specifically setup to wrap and call the original Exec routines and providing a forwarding validation of things like IDNestCnt as it is legitimate to Clone ExecBase (therefore providing a template restore point of limited usage with the exception of the ExecBase contained List structures)

it is more than plausible for 68K, PowerPC, ARM and x86 variations of the "micro kernel" design to be radically different yet provide the same "face" to Applications using them.

This also allows for SMP to be a bolt-on after release consideration without major OS surgery... the question then becomes how the applications will perform given those changes.

and the more an Application has used the OS calls and not direct access the safer it will be.

a simple "unsafe" flag can be used as part of the Extended structure attached behind a task structure for CPU specifics (this allows for SMP within the existing design to be included).

so I still don't get why this subject comes up as "not possible" so dammed much...

Go read Dave Haynies Documentation...and THINK... the AA3000 that he built had an "ACTIVE DSP" with Soft-Modem capability...

Multiple-Processors on an Amiga HAS ALREADY BEEN DONE ON THIS PROTOTYPE SYSTEM.

So the argument of "it can't be done" is bullshit as provided by Dave H.s own prototype which he was *actively* using as a personal machine (Deathbed Vigil post-production was done on the same machine I think...need to verify on the youtube interview if it was the same machine or not).

EDIT: Who else has used an A2088, A2286, A2386SX or equivalent CPU equipped "Bridgeboard"... as that was an additional processor with support chips as well...
Any "Bridgeboard" equipped Amiga 68K system is already multi-processor.

These examples a;ll prove how resilient the existing exec design is... do we need to radically change the system for updating it? or only add essential code for the new features?

I only see the need for required code and no more along with support hardware as needed.

Last edited by Belxjander on 27-Aug-2014 at 07:35 AM.

@Belxjander

The issue umisef was discussing was obviously that on the original hardware, only ONE physical CPU would access those things which actually NEEDED atomicity, like a variable accessed both by an interrupt and by the main code. Even if you have multiple things doing things at the same TIME, this is not a problem as long as they're not doing the SAME thing at the SAME time.

On AVR I typically use the avr-gcc equivalent of forbid();copy_out_status_flags();clear_status_flags();permit();process_status_flags();

But this is with only one core, with two cores this would mean a major performance hit if ALL cores had to be shut down every time I needed some critical info in a thread.

I do wonder how one would use the lwarx and stwcx instructions mentioned by Itix to somehow emulate the missing atomicity of the m68k instructions in the emulator. What does Petunia currently do about this? Obviously the problem is there even without multiple concurrent threads entering the picture.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Well...in the case of multiple processors...you have only a single core start...and then use the SMP controller to "enable" additional cores once multitasking is prepared to accept them
then you specifically run a "launcher" routine using the CPU startup mechanism.

in the 68020+ CPU range...this is to read location 0 and location for as an "Initial Program" and "Initial Stack" Address pair (32bit address limitation).

As you can have the VBR on the boot processor "relocated" and then assign the original ChipRAM $0 & $4 to being alternate values...running the 2nd processor launches a minimal "bootstrap" routine to prepare the CPU and switch to the first task available to run...

so bootstrap "exec/expansion" and preload ALL the device drivers...then lock them to the primary CPU when enabling multiprocessor semantics...and launch the additional processors.

each Core then can "read" the SMP for a fixed CPU_ID for which core it is (0 == Boot) and run Application tasks all day until switched off.

the ETask structure behind the Task structure is a very good place to look for this information.

and on the 68K you can hard-lock multiple processors sharing an extended "Co-Processor" which ID's each chip by which "CPU face" it is wired to.

as the "cpXXXX" semantics are the same for the FPU, MMU and any "MPU" SMP hardware implimented in a similar way to the 68881 sync-locked FPU...this makes MPU access also semaphore in hardware compliant regardless of the number of CPUs, along with giving the SMP controller MPU a means of halt-locking CPU's mid-access and they hold state until the HALT signal is off...

this gives an immediate and safe means of hard-locking the CPU without changing the OS beyond a minimal routine

@Belxjander

That's just gibberish. The problems of enabling SMP or near-SMP on AmigaOS are well known.

. forbid/disable must work as they have
. this means that when e.g. forbid is called/executed the caller have to be able to access the whole system as an atomic operation until permit is executed.
. RMW instructions must be atomic
. Interrupts must be atomic to non-interrupt code.

The third point isn't fixed into stone - the system could allow rewrites of interrupt handlers to not expect atomic semantics who then are installed with a new Exec function.

Now it could be possible to do this using x86 processors:
. x86 support exceptions when writing/reading a memory location - using the debug registers. This could _probably_ be used to support atomic execution of forbid state.
. RMW instructions are atomic.
. Interrupts could be wrapped.

How: debug registers for all processor cores are set to trigger an exception when writing to the forbid/disable locations. That means that one core writes one of those
locations all cores will trigger a debug exception.

The exception will then allow the one core that wrote a new value to continue execution while the others are set to spin on the value. When the permit/enable condition is reached those other cores will exit the spin loop and return from the debug exception.

Interrupts would use a similar mechanism as the forbid support.

@megol

>It is easy making "AmigaOS" SMP capable by killing compatibility - but then it isn't an Amiga anymore.

There is a lot of us who think the compability is not what makes an Amiga.

>It is in fact trivial to make an Exec clone with SMP support, that isn't the problem. Compatibility is.

I would love to see SMP and memoryprotection tolerant Amigalike API to be available NOW.
(sandbox for legacy stuff could appear later if there is need for it, beyond UAE, in the meanwhile people could also reboot to AOS4.1 or MorphOS3 if needed ... One way is to use HW assisted virtualization & partitioning to hide the modern side from the legacy side.)

So far, to me it seems AOS4 is going via the hardest way, updating the old.

It will be interesting to see what ARIX API (SMP etc:) will be like ... (I wish not too much foreign for Amiga developers)

To my understanding MorphOS team hope to have basic portable application set ready when they do the big shift to modern age (potentially with ISA change). But no roadmap available, they do what they like/want to do. But as MorphOS looks & feels so mature ... I imagine they might be ready & ancious for the next big challenge. (I doubt modern variant beside legacy compatible one would not hurt Morph or Amiga licence sales.)

Last edited by KimmoK on 27-Aug-2014 at 11:35 AM.
Last edited by KimmoK on 27-Aug-2014 at 11:32 AM.
Last edited by KimmoK on 27-Aug-2014 at 11:28 AM.

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

@megol

Quote:

It is easy making "AmigaOS" SMP capable by killing compatibility - but then it isn't an Amiga anymore.

I don't see why compatibility has to be killed. At least with 68K, because that runs in an emulator. All you have to do is change the nature of the emulator. Given RunInUAE is now installed as a add on with Workbench 3.1 this may signal an intent to take the easy road out. Just look at how Apple emulated OS9 with it's own sandbox. To me it looked silly and over the top to boot an old Mac OS on top of a new Mac OS. But if course, OSX wasn't a real Mac OS, in respect to the original.

One of the big deals with OS4 was that each 68K program ran like on the original OS, as its own task within the system, in this case a 68K emulation program run as each 68K task using the 68K code as its data.

I think at this point they should sperate 68K system structures and native OS4 system structures. Therefore any change to freeze tasks or interrupts would only happen within the 68K subsystem. Leaving the main OS4 system safe from manipulation.

Another idea, one what I have had, and IIRC is being worked into AROS, is to use an emulator like UAE as a base but hook into all the OS calls and reroute them to the native host OS. So OpenWindow() would end up calling the host OS, like it does now, but with a protective layer. The upshot if this would be that hardware banging code would work instead of crashing or dissappering.

Also, keeping ExecBase readable at location 4 in PowerPC code was a bad idea, especially in an interrupt. There was no need before this. Every start() code entry or interrupt routine can easily have ExecBase passed as an argument. Another thing was how PPC interrupts are added to the system. Taking CIAgent as an example, I didn't want to, but I was forced to use Disable() and SetIntVector() to patch myself in. Had they let AddIntVector() work, and the autodoc indicated it would work, I could have used a safer OS-in-control "method" of adding an interupt. Against this, they say they don't want people using these low level routines. But, without providing a safer way to add an interrupt or what I would prefer, an emulation hook to catch chip mem access, they force my hand.

Now, something that has annoyed me, GetCC(). They let 68K programs "hack" TDNestCnt but with a function designed as a safe way to get processor flags, GetCC(), they kill off and return zero! What the hell!? I wanted to use it when patching debugger code to work on OS4 68K emulation. Well, once again, my hand was forced and I used the MOVEC CCR instruction instead which works! What's the point of all that!?

@KimmoK

they go that way because of the limited resources (SMP f.e. not only needs a lot of changes but also lots of testing) and because otherwise compatibility would be broken and many 68k software would only run in UAE (basically the concept AROS is using). I read somewhere from MorphOS devs that "if" they would make a ISA change 68k would run in UAE and they would add modern features like SMP and 64bit (and because of all that such a ISA change would need years). So short, modern features and running old 68k software like people are comforted to will not work.

I have read some comments from Geit, one of the developer, and to me it seems that it is not yet decided if they should make the ISA change (what needs years) or optimizing what is there and adding applications. Depending on your view there are reasons for both.

Last edited by OlafS25 on 27-Aug-2014 at 01:12 PM.

@Hypex

Well yes sandboxing is one way to do it and keepin the cake (=compatibility). That is obvious however Hyperion never liked going that way. Or supporting x86 for that matter.
Doing those things somehow would kill the Amiga - according to them.

@Hypex

Quote:

Also, keeping ExecBase readable at location 4 in PowerPC code was a bad idea, especially in an interrupt. There was no need before this. Every start() code entry or interrupt routine can easily have ExecBase passed as an argument.

It is not possible. All 68k programs are PPC programs (executed by interpreter or translated to PPC) and PPC native code can jump at anytime to 68k code or vice versa. Therefore both executables must have same "privileges" in the system.

For example you can have PPC native executable using 68k libraries and classes, even devices. 68k native program on the other hand is making calls to PPC libraries, classes and devices.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Quote:

megol wrote: @Belxjander That's just gibberish. The problems of enabling SMP or near-SMP on AmigaOS are well known. . forbid/disable must work as they have . this means that when e.g. forbid is called/executed the caller have to be able to access the whole system as an atomic operation until permit is executed. . RMW instructions must be atomic . Interrupts must be atomic to non-interrupt code. The third point isn't fixed into stone - the system could allow rewrites of interrupt handlers to not expect atomic semantics who then are installed with a new Exec function. Now it could be possible to do this using x86 processors: . x86 support exceptions when writing/reading a memory location - using the debug registers. This could _probably_ be used to support atomic execution of forbid state. . RMW instructions are atomic. . Interrupts could be wrapped. How: debug registers for all processor cores are set to trigger an exception when writing to the forbid/disable locations. That means that one core writes one of those locations all cores will trigger a debug exception.

Using the debug registers is exactly the idea that I had, but the problem is that it's not 100% clear what happens on a multi-core system.
Quote:

The exception will then allow the one core that wrote a new value to continue execution while the others are set to spin on the value. When the permit/enable condition is reached those other cores will exit the spin loop and return from the debug exception.

This is the only diverging point: why the other cores should be blocked while one is inside the critical section? IMO they should continue to run until one tries to enter the critical section: now it should be blocked and it must halt until the other core leaves the critical section.

This way the system can run at the maximum speed.
Quote:

Interrupts would use a similar mechanism as the forbid support.

Yes. There are 4 debug registers that can be used to track 4 different locations.

@all: IMO the thread is mixing too much things. Maybe it's better to define the specific scenarios, such has: SMP on an multi-core 68K system (o.s.: AROS, a patched Amiga o.s.), or on a multi-core PowerPC system (o.s.: OS4, MorphOS), or on a multi-core x86/x64 system (o.s: AROS, ARIX).

@cdimauro

I agree on the diverging of the thread, but welcome to AmigaWorld, the place where all threads this last decade has ended up including the same arguments

If it really is inherently impossible to make AOS SMP on PPC but not on x86, I for one WOULD welcome AOS on x86, but as I've said about a thousand times by now, that's what AROS is for in the first place. All AROS needs is a PLAN, in my opinion.

But I'm not so sure that this is indeed true, since semaphores work just fine on PPC.

If Petunia can handle it (it claims it can) and UAE can handle it (can't see why not) then we're left with some examples of AOS 4.1 software that potentially needs reworking, which I feel should be viewed as a challenge and an opportunity, not a problem.

Possibly a JIT-capable UAE with good system integration is a better approach than Petunia anyway, in the long run.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@megol

I was making reference to low-level details and semantics of the existing "classic amigaos" and the M68K architecture specifically.

68020 and newer Processors include "Co-Processor" instruction options for additional chips to extend the CPU (using this interface each "CPU" is then halt-lockable during the use of a hardware semaphore and exclusively blocking on access to this which does give a minimal protection for task-switching and other limited core functions without killing the system to run multiple-processors independently)

I am not as familiar with the "x86" registers for debug purposes and did not imply beyond that the support was present on that architecture.

as for "All cores trigger a debug exception"...this would be an SMP event therefore using any SMP support hardware to identify and manage such an exception.

Only the core that is set for accepting interrupts will run them otherwise they are ignored.

As for the rest...I'm not going to bother repeating myself as Multi-Processor support has been done.

I even gave a reference example.

as for the atomicity of any given instruction, that is a hardware issue not solvable entirely by software (any wrapper of exec would need to support specialist hardware extensions for multiple processors for any kind of implimentation).

"Atomicity of Interrupts" is that only one core runs the interrupt at any given time while the other cores skip processing the event (that is if the hardware even lets them see it).

Go read the Dave Haynie Archives on thule.no with regards the Gemini project...
and THEN take another look at my "Gibberish" and maybe...just maybe you will get a clue as to what I was discussing.

Exec itself with regards the Interrupt handling or anything else does not need to be specifically re-written. (it is possible to "protect" the exec call function set or sub-sets of the Library Functions presented so that there is no deadlocking options.

@itix

Quote:

Therefore both executables must have same "privileges" in the system.

For 68K they can keep it, but on PowerPC ExecBase should be in a register so it isn't read the old way. I've looked at PPC interupt code where it reads ExecBase from $4 and am shocked they would allow that or even do that when data can be passed to an interrupt. For one thing, that interrupt would be interrupted by a DSI or however they program the MMU, that would then load the pointer in for the orginal interrupt. It just looks dirty.

We are told for years to cache ExecBase. Well they should have done that from the start. ExecBase should have been in A6 already so programs can store it! And location 4 should have been a trade secret. It's the OS business to know where ExecBase is stored as a static pointer, not the programs.

@Belxjander

Quote:

Exec itself with regards the Interrupt handling or anything else does not need to be specifically re-written.

That reminds me. I think with the current way of doing things like the OS disabling multitasking to lock a semaphore could be done by triggering an interrupt to lock it instead. That way, the code is protected from being kicked out, and avoid diabling multitasking aT the cost generating an interrupt.

@Itix

Quote:

It is not possible. All 68k programs are PPC programs (executed by interpreter or translated to PPC) and PPC native code can jump at anytime to 68k code or vice versa. Therefore both executables must have same "privileges" in the system.

One problem whit this debate, is that people seams to think that new programs will need to follow old guide lines, this is false.

New program will be calling API's to do its dirty stuff, and the OS need to do is serialize what is coming from this API's with the rest. Should be simple to do. (but I'm sure there is a lot of work, to find out what API's that needs to be serialized.)

@Belxjander

Quote:

Only the core that is set for accepting interrupts will run them otherwise they are ignored.

http://stackoverflow.com/questions/301018/how-do-interrupts-in-multicore-multicpu-machines-work

Well according to Linux geeks, you can define what core that should be used when you get interrupts. Interrupts are not ignored, the lose of a interrupt can be big problem for the driver, if it does know that some thing has happened. (I mean you can lose TCP/IP packages, or miss som sound in a recording and disk IO can run slowly because driver did not get response it was expecting with in timely fashion.)

The bigger issue is that interrupt on core 0 will be running in parallel to schedules task on core 1 and 2, this means that all drivers will need to be thread safe.

I don't think this be problem because interrupt on singe core CPU's can happen at any time, and so the integrity of the system when a interrupt has happened is uncertain even on a single core CPU. But to make sure noting bad happens it be best if the device/driver process is scheduled to run on the same core as interrupt service.

Another quote from interesting commodore document.

http://archive.org/stream/International_Amiga_Developers_Conference_Notes_1993_Commodore/International_Amiga_Developers_Conference_Notes_1993_Commodore_djvu.txt

“It is important to understand that when entered via
NMI, many system lists may be in unstable states. (NMI can happen in the middle of the AllocMemO routine or task switch, etc.)“

@AmigaOS4 Beta tester and AmigaOS4 developers.
Nice if some downloaded the document cleaned it up, and uploaded it amigawiki pages.

Last edited by NutsAboutAmiga on 28-Aug-2014 at 09:58 PM.
Last edited by NutsAboutAmiga on 28-Aug-2014 at 04:28 PM.
Last edited by NutsAboutAmiga on 28-Aug-2014 at 04:20 PM.

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