@NutsAboutAmiga

Quote:

Well its possible that JIT compiler breaks some thing that should be atomic,

It's not only possible, it's a certainty. That's the problem with a task-based emulation --- because the PPC task scheduler is unaware of what the emulated process is doing, it may decide to preempt in the middle of what is meant to be an atomic 68k operation.

Quote:

I say the design is broken if they depend or hope some 68k assembler opcode is atomic.

Why? 68k has plenty of instructions that read *AND* write memory (mostly read-modify-write, but IIRC, you could also have MOV instructions with both source and destination being memory?). And no 68k processor ever produced would handle an interrupt mid-instruction; Interrupts (and thus re-scheduling) would only ever happen on instruction boundaries.

So on any real 68k Amiga, "ADD.B #1,(A0)" to increment a reference counter and "SUB.B #1,(A0)" to decrement it are perfectly valid, perfectly atomic instructions. Nothing could possibly go wrong (related to concurrency, at least :). It is sound design.

The PPC simply does not have read-modify-write instructions. Thus, the above would necessarily be translated into an "LD" memory read, followed by some instructions implementing the add/subtract, followed by an "ST" memory write. And obviously, if an interrupt and reschedule happens between the LD and the ST, things can go horribly wrong.

This issue could be avoided if the PPC interrupt was disabled around JIT-generated code corresponding to atomic-on-real-68k instructions. But disabling/enabling interrupts is not something you want to try millions of times per second.


None of this, of course, applies to actual multiprocessing, with multiple processing cores. Then read-modify-write becomes non-atomic even on 68k. There is probably a good reason why there has never been any kind of SMP Amiga --- AmigaOS 68k has a number of atomicity promises which go out the window when you start running multiple cores.

@cdimauro

Quote:

Fine, but a question here to better clarify: are PowerPC applications allowed to directly access and modify IDNestCnt, for example, as 68K apps did?

PowerPC applications are allowed to access and modify IDNestCnt.

Quote:

PowerPCs has to execute 3 instructions to do the same: the load, the increment, and then the store. They are not atomic, and a scenario similar to 68K can happen (with external peripherals accessing the same location, for example). You talked about atomic instructions for PowerPCs, so I assume there's a way to "own" changing a memory location (which is a common feature for processors). So, the real question is: there are guidelines for PowerPC applications which force them to use such atomic instructions to change o.s. data like IDNestCnt?

PowerPC has special load and store instructions to modify memory atomically: lwarx and stwcx.

"The lwarx and stwcx. instructions are primitive, or simple, instructions used to perform a read-modify-write operation to storage. If the store is performed, the use of the lwarx and stwcx. instructions ensures that no other processor or mechanism has modified the target memory location between the time the lwarx instruction is executed and the time the stwcx. instruction completes."

http://www-01.ibm.com/support/knowledgecenter/#!/ssw_aix_71/com.ibm.aix.alangref/idalangref_lwarx_lwri_instrs.htm

Since lwarx and stwcx only work with 32-bit words while IDNestCnt is only 8-bit you have to be very careful to not alter other bits.

MorphOS SDK has macros to atomically modify 32-bit words. None of them work with IDNestCnt though and generally nobody is using IDNestCnt directly anymore. It is too low level. But it is still legal if someone want it...

Quote:

Quote: On OS3 PPC can not access OS structures at all because there are two separate CPUs running simultaneously. Strange. I thought that the PowerPC had access to whole Amiga machine memory.

It has but concurrency issues are unsolvable.

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

@itix: thanks for the info. So technically PowerPC applications can do whatever they want, but practically nobody does it.

At this point, I think that trapping the Forbid / Permit for PowerPC apps (and polite 68K ones) and accesses to IDNestCnt for (not so much polite) emulated 68K apps can provide a solution to implement SMP on MorphOS and OS4.

@umisef: the chipset can write to the A0 location of the "ADD.B #1,(A0)" instruction just after the CPU has read its content, if A0 stays in chip ram. And in general, a peripheral can do it on any kind of memory.

That's on the real hardware. Emulating a 68K atomicity can be achieved, as itix suggested, so there's no problem here.

@itix

Quote:

Uhm, and you never crash OS4?

Of course I have. Did you miss my DOS API example?

Quote:

If you have CyberGuard

Yeah, if. I"m talking about OS4 having built in protection without adding hacks or serial cables, which it does. Might not catch everything but better than nothing.

Requiring to install programs and hardware to catch illegal access is going to far. This is fine for a developers enviroment but not the average user who shouldn't have to be a tech head just to see how clean a program is.

@NutsAboutAmiga

Quote:

IBrowse is old and dose not support HTML5 nor CSS, renders most web pages wrong, and too anying for my taste.

I like to use it for webmail and AW. It knows my bookmarks and passwords.

Plus without session saving to slow it down it loads quick.

And AFAIK it is the only Amiga browser that ever supported flash with a plug in. And can print PS to a file, for web printing work around using AmiGS.

Last edited by Hypex on 25-Aug-2014 at 08:51 AM.

@NutsAboutAmiga

Quote:

all the programs sees is empty string at address 0x00000000.

That depends. The exception trap code may not write zero into the load register. So what could be left is the last value and if the last value is non-zero then the code will go on forever. So even a "zero at zero" isn't safe.

Quote:

As long as the application does not try write "hello world sucker" at address 0x00000000,

LOL! Even on OS3 that would crash as corrupting ExecBase will destroy the OS in a flash.

@cdimauro

Quote:

Just after the first step another peripheral can take ownership of the bus and write a new value in the location.

That's an interesting point that I didn't know about, but how likely is that on AmigaOS? I mean, if we take Forbid, Interrupt and semaphore counters into consideration, the hardware would need to be well setup for a peripheral to even know and modify those locations.

I take it BSET has the same atomic issue? Read, modify, write?

Quote:

At this point, I think that trapping the Forbid / Permit for PowerPC apps (and polite 68K ones) and accesses to IDNestCnt for (not so much polite) emulated 68K apps can provide a solution to implement SMP on MorphOS and OS4.

I don't know why they let this become a problem in the first place. OS4 should have been a clean break. There shouldn't need to be an OS4SG (second generation) in order to modernise the OS for multi core hardware. The only reason to keep the original structure was compatiibility for 68K apps and oh, there it is; 68K apps run in emulation. So I see no need to use original structures at all. I think they should have emulated the orginal structures and left it at that in a sanboxed enviroment. Sure, each 68K task could have been a seperate emulation, like it is now, but resricted to a 68K only ExecBase.

Given they changed library with interfaces anyway why not go the whole way? Keep a compatibily layer for the old apps and build on it with new ideas for the new OS. Well too late now. Ten years past, time to reimagine the wheel again.

Last edited by Hypex on 24-Aug-2014 at 05:40 PM.

@umisef

Quote:

It's not only possible, it's a certainty.

Well its hypothetically because we taking about one program in particular, because we taking about one program we do not know if has or has not used atomic instructions, my hunch is that they have because it breaks in one of its child processes, and only under JIT.

Quote:

Why? 68k has plenty of instructions that read *AND* write memory (mostly read-modify-write, but IIRC, you could also have MOV instructions with both source and destination being memory?). And no 68k processor ever produced would handle an interrupt mid-instruction; Interrupts (and thus re-scheduling) would only ever happen on instruction boundaries.

That can be, but this was program created after AmigaOS4.0 was released with the intent it was going to work running on JIT, until it was ported to PowerPC. So there for it should be designed to work on JIT, and there for its broken by design. In my option, again if they used atomic instructions.

Quote:

None of this, of course, applies to actual multiprocessing, with multiple processing cores. Then read-modify-write becomes non-atomic even on 68k. There is probably a good reason why there has never been any kind of SMP Amiga --- AmigaOS 68k has a number of atomicity promises which go out the window when you start running multiple cores.

Yes the thing that worries me is data cache, but I no expert on how this works.
I assume shempore / mutex locks and can in theory force data cache flushes, but maybe data cache is shared between CPU cores on modern CPU'S, or how does this work?

Last edited by NutsAboutAmiga on 25-Aug-2014 at 03:41 AM.
Last edited by NutsAboutAmiga on 24-Aug-2014 at 07:16 PM.

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

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Just after the first step another peripheral can take ownership of the bus and write a new value in the location. That's an interesting point that I didn't know about, but how likely is that on AmigaOS? I mean, if we take Forbid, Interrupt and semaphore counters into consideration, the hardware would need to be well setup for a peripheral to even know and modify those locations.

It can happen if, for example, the Blitter is writing on the same location, just after that the CPU has read the value. But the same can apply to the disk, a Zorro peripheral, or a co/processor running in parallel in an expansion board.

I think it's unlikely, but not impossible.
Quote:

I take it BSET has the same atomic issue? Read, modify, write?

Yes, exactly. Only a few 68K instructions are atomic (TAS, CAS), but their use is prohibited by the Hardware Manual.
Quote:

Quote: At this point, I think that trapping the Forbid / Permit for PowerPC apps (and polite 68K ones) and accesses to IDNestCnt for (not so much polite) emulated 68K apps can provide a solution to implement SMP on MorphOS and OS4. I don't know why they let this become a problem in the first place. OS4 should have been a clean break. There shouldn't need to be an OS4SG (second generation) in order to modernise the OS for multi core hardware. The only reason to keep the original structure was compatiibility for 68K apps and oh, there it is; 68K apps run in emulation. So I see no need to use original structures at all. I think they should have emulated the orginal structures and left it at that in a sanboxed enviroment. Sure, each 68K task could have been a seperate emulation, like it is now, but resricted to a 68K only ExecBase. Given they changed library with interfaces anyway why not go the whole way? Keep a compatibily layer for the old apps and build on it with new ideas for the new OS. Well too late now. Ten years past, time to reimagine the wheel again.

It's too late. To make a successor of an Amiga o.s. which is modern and solid, many things had to be change. So many, that it means practically rewriting the o.s. and the applications.

What was made by successors, legitimate and not, is to continue using the same APIs, data structures, and making additions on top of it. Adding new features, like multicore support, is tough in the same way: patching the existing the minimum possible to get some gain.

I think it's wrong, but, in the end, who can put so much resources (time, money) to create a clean, albeit strongly Amiga o.s.-inspired, design with all modern features?

@cdimauro

Quote:

It can happen if, for example, the Blitter is writing on the same location, just after that the CPU has read the value. But the same can apply to the disk, a Zorro peripheral, or a co/processor running in parallel in an expansion board.

However, if you have the blitter or disk controller write to the memory which you use for a reference counter, or for thread synchronisation, then you have a bigger problem than non-atomic updates. You have memory corruption. Because neither disk controller, nor blitter, should ever be concerned about those memory locations, anyway.

On the other hand, two 68k threads/tasks under AmigaOS are perfectly fine relying on atomicity of RMW instructions on any real 68k Amiga. Not so, however, in task-based emulation (JIT or non-JIT, doesn't matter) on PPC, unless one has gone to rather difficult lengths to delay PPC interrupt handling until an 68k instruction boundary is reached (which, given that the PPC interrupts are actually real, hardware interrupts, ends up being a rather atrocious hack at best).

Of course, once you start going multi-core, you run into other issues as well. The most obvious example is that on single-core, interrupt handlers are atomic with regards to non-interrupt code. On multicore, no longer true.

Quote:

umisef wrote: @cdimauro Quote: It can happen if, for example, the Blitter is writing on the same location, just after that the CPU has read the value. But the same can apply to the disk, a Zorro peripheral, or a co/processor running in parallel in an expansion board. However, if you have the blitter or disk controller write to the memory which you use for a reference counter, or for thread synchronisation, then you have a bigger problem than non-atomic updates. You have memory corruption. Because neither disk controller, nor blitter, should ever be concerned about those memory locations, anyway.

Of course. I've only showed why it's not true that a real 68K has atomic instructions.

In our specific case (multi-core support for an Amiga/like o.s.), a PowerPC processor running on an expansion board is a better example: it can access to any memory location, contending it with the 68K.

@pavlor

A snippet from post #1.

**That’s the way Amiga OS manage multi-core systems (in fact, it goes even further by making light copies of the OS running on each secondary core). **

The way I see this is a concept of what could be possible. Lets say for example the OS running on the second core is a cut down and very much specialized version that caters to doing one thing without consideration for those functions that may decrease its performance or interfere with its single minded task.

A music OS.
A video OS.
A graphics OS.
A gaming OS.
etc..

(Perhaps the gaming OS could incorporate that Steam Engine thingy.)

When running a specialized OS the main OS becomes subservient to that system for things such as harddrive access, network, etc..

Just a thought.

_________________
Tinkering with computers.

@NutsAboutAmiga

Quote:

Well its hypothetically because we taking about one program in particular, because we taking about one program we do not know if has or has not used atomic instructions, my hunch is that they have because it breaks in one of its child processes, and only under JIT.

It shouldn't matter in any case as any atomic operations manipulating OS counters should be done in the OS function. Be that 68K or PPC, if if modifies OS data directly, then it is broken and dangerous.

Quote:

That can be, but this was program created after AmigaOS4.0 was released with the intent it was going to work running on JIT, until it was ported to PowerPC.

Actually IBrowse is semi-native. It includes a PPC native javascript.library.

@cdimauro

Quote:

I think it's wrong, but, in the end, who can put so much resources (time, money) to create a clean, albeit strongly Amiga o.s.-inspired, design with all modern features?

The AROS Team?

@Signal

Quote:

Lets say for example the OS running on the second core is a cut down and very much specialized

That depends on what you would call the OS. Sure the OS includes applications. But I've been told that AmigaOS doesn't really run like a program, that it runs as an interrupt. So the core of AmigaOS is really a set of interrupts.

@umisef

Quote:

umisef wrote: @cdimauro Quote: It can happen if, for example, the Blitter is writing on the same location, just after that the CPU has read the value. But the same can apply to the disk, a Zorro peripheral, or a co/processor running in parallel in an expansion board. However, if you have the blitter or disk controller write to the memory which you use for a reference counter, or for thread synchronisation, then you have a bigger problem than non-atomic updates. You have memory corruption. Because neither disk controller, nor blitter, should ever be concerned about those memory locations, anyway. On the other hand, two 68k threads/tasks under AmigaOS are perfectly fine relying on atomicity of RMW instructions on any real 68k Amiga. Not so, however, in task-based emulation (JIT or non-JIT, doesn't matter) on PPC, unless one has gone to rather difficult lengths to delay PPC interrupt handling until an 68k instruction boundary is reached (which, given that the PPC interrupts are actually real, hardware interrupts, ends up being a rather atrocious hack at best).

But keeping the RMW atomicity is trivial when running on a custom FPGA processor _or_ x86. All RMW instructions with an aligned memory access are atomic on x86 and AMD64 (I think you already know this but others here may not).

Quote:

Of course, once you start going multi-core, you run into other issues as well. The most obvious example is that on single-core, interrupt handlers are atomic with regards to non-interrupt code. On multicore, no longer true.

It isn't that hard to keep that guarantee at least with custom hardware (FPGA processors). With some wrappers it should be doable using an off the shelf processor running an emulator too.

I've proposed some simple hardware to support forbid()/disable() semantics on a multi-core or multi-threaded FPGA soft core but my limited knowledge of the Amiga OS internals means that I cannot prove this would be enough to support semi-SMP with a mostly compatible Amiga clone.

In short my proposal consists of:
. RMW instructions are atomic - using cache line locking for cacheable memory and a global hardware lock for non-cacheable memory.
. Forbid/Disable are detected by dedicated snooping hardware and enforces single processor semantics - using a global lock in the beginning, cache level locking is more complicated but would increase performance.
. Interrupts gated into a single processor core at the start.

The idea is that the SMP is allowed to convert to a single processor system when required for compatibility while keeping most of the SMP advantages.

Quote:

Hypex wrote: @NutsAboutAmiga Quote: Well its hypothetically because we taking about one program in particular, because we taking about one program we do not know if has or has not used atomic instructions, my hunch is that they have because it breaks in one of its child processes, and only under JIT. It shouldn't matter in any case as any atomic operations manipulating OS counters should be done in the OS function. Be that 68K or PPC, if if modifies OS data directly, then it is broken and dangerous.

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

Hypex wrote: @cdimauro Quote: I think it's wrong, but, in the end, who can put so much resources (time, money) to create a clean, albeit strongly Amiga o.s.-inspired, design with all modern features? The AROS Team?

Can be.

Quote:

megol wrote: But keeping the RMW atomicity is trivial when running on a custom FPGA processor _or_ x86. All RMW instructions with an aligned memory access are atomic on x86 and AMD64 (I think you already know this but others here may not).

I've already reported it. It's a great feature that can help a lot the performance.
Quote:

Quote: Of course, once you start going multi-core, you run into other issues as well. The most obvious example is that on single-core, interrupt handlers are atomic with regards to non-interrupt code. On multicore, no longer true. It isn't that hard to keep that guarantee at least with custom hardware (FPGA processors). With some wrappers it should be doable using an off the shelf processor running an emulator too. I've proposed some simple hardware to support forbid()/disable() semantics on a multi-core or multi-threaded FPGA soft core but my limited knowledge of the Amiga OS internals means that I cannot prove this would be enough to support semi-SMP with a mostly compatible Amiga clone. In short my proposal consists of: . RMW instructions are atomic - using cache line locking for cacheable memory and a global hardware lock for non-cacheable memory. . Forbid/Disable are detected by dedicated snooping hardware and enforces single processor semantics - using a global lock in the beginning, cache level locking is more complicated but would increase performance. . Interrupts gated into a single processor core at the start.

Maybe this can work on a regular x86 or x64 processor, so without necessarily going to an FPGA implementation. But it requires deeper investigation (I've some idea, but it has to be verified).
Quote:

The idea is that the SMP is allowed to convert to a single processor system when required for compatibility while keeping most of the SMP advantages.

My idea is that only one processor can execute a critical (forbidden) region, but it's made without blocking the execution of the other processors. Only if another processor tries to execute a critical region it has to be blocked until the first processor exits from the critical region.

This doesn't compromise the performance of the Whole system. But, as I said, it has to be investigated.

P.S. Maybe there's no need to have the current task pointer set to NULL on ExecBase, and in general to have NULLs or zeros on some ExecBase structure. At least on x86 and x64, because they have some mechanism to avoid such solution.

And there is ONE detail which everyone here seems to have danced around...

That is the issue of bus level access to memory outside what is present forcing a bus fault...

And "bus fault" events on AmigaOS are an immediate guru... but in the case of the 040 and 060 the CPU "reset repeats" the access and can trigger a double-bus-fault condition.

This *will* hard-lock the CPU to a non-execution halt state regardless of what was happening.

Despite this... the issue appears to be keeping a sync-lock on specific values,
one option I would consider would be a "sync lock memory" and OS structures with atomic access issues have allocations marked for sync-lock within the memory concerned.

this would push all sync-lock issues to a single-memory region with controller just for this.

in any case...any given solution to the problem would require massive changes.

as for "looking to the future" and specifically arguing for x86/arm based on AROS seems to miss a major point in that AROS itself is written open source and actively developed for those architectures.

OS4 and MOS both are developed for different variations of available PPC machines with some common boards as well.

Afaik there is more support with PPC/x86/ARM architectures for SMP...so just sorting out an atomic-access mechanism when emulating 68K on the above may be a good first step towards solving SMP generally.

Everyone here may not agree as to "memory protection" (and I certainly question usage of that term) and other details.

@Belxjander

I found it funny to read that the conclusion was almost "SMP is impossible because of mechanism that makes JIT m68k also impossible, this mechanism being PPC interrupts". As we all know, m68k JIT is already in use in OS4, albeit with a blacklist.

If this blacklist was transferred on to an SMP implementation, so that any software that was on the blacklist would need to lock all cores to be scheduled, my naive understanding of the issue would seem to indicate that while sub-optimal (I would tend to call the optimal solution "non-realistic", but then again I failed the optimized regulation course in the university several times), it's possible.

Not being on the inside regards to OS4 kernel knowledge is REALLY starting to gnaw at me

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

@cdimauro
Quote:

cdimauro wrote: Quote: Hypex wrote: @NutsAboutAmiga It shouldn't matter in any case as any atomic operations manipulating OS counters should be done in the OS function. Be that 68K or PPC, if if modifies OS data directly, then it is broken and dangerous. 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.

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.

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 to support support workarounds for poorly coded applications.

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