@Hypex

Quote:

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.

True but you can use a Mutex its already forbid free.

Last edited by NutsAboutAmiga on 28-Aug-2014 at 07:51 PM.
Last edited by NutsAboutAmiga on 28-Aug-2014 at 04:33 PM.

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

@Hypex

Quote:

For 68K they can keep it, but on PowerPC ExecBase should be in a register so it isn't read the old way.

68k emulation could do that: switch global exec base on when entering 68k emulation and switch it off when exiting 68k emulation. But it would hamper overall performance. It is not worth of trouble.

Quote:

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.

There used to be good reason for that: it was located in very slow chip ram. Today we dont have chip ram anymore and this problem is gone. But it can trigger MMU exception (to detect NULL pointer read) so it is still good idea have it cached always.

But it is not "dirty" per se. It is just less efficient.

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

@NutsAboutAmiga

Quote:

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

You cant know what guide lines new programs are following. Complex guide lines suck because developers dont care or remember.

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

Quote:

olegil wrote: @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

In reality I wasn't talking about the diverging of the thread, but regarding the mix of different thing without a clear context.

I think that such kind of discussions are very interesting, because every Amiga/-like o.s. has basically the same issues regarding the SMP support. So maybe some solutions can be found by comparing the different needs of the o.ses and the ideas of all users contributing to the thread.
Quote:

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's the solution that I like, because you don't have to care of the limits and constraints of the past: put everything on a sanbox, and trace a better, and modern way for a new Amiga-inspired o.s..

Quote:

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

Who claimed this? Nobody AFAIK. The problem here is regard keeping the backward compatibility with the old apps (both 68K and PowerPC, since they are first-class applications) while introducing the SMP support.

Of course, if there are new guidelines the new or updated applications should take care of them, hoping that they are not too much complicated, as itix correctly stated.
Quote:

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

Fine. But it isn't the main problem discussed here.
Quote:

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.)“

NMIs were very rare. Anyway, they can run without touching the system structures.
Quote:

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

I agree. The document is very good, but the formatting is horrible.

@NutsAboutAmiga

Quote:

True but you can use a Mutex its already forbid free.

I could but on AmigaOS Semaphores were provided for the same sort of purpose. And despite them changing the API (or rather the structure which looks dangerous for old ones) they work fine as far as I can tell. As to being forbid free that is up to the OS function. It has a counter. I can think of ways to avoid forbidding but a task still has to be added to a list and that will require some sort of forbid state. A Mutex (with no known structure on OS4 AFAICT) must be a simpler device with a task pointer.

Last edited by Hypex on 29-Aug-2014 at 03:30 PM.

@itix

Quote:

But it would hamper overall performance. It is not worth of trouble.

I don't mean anything like that. I mean, interrupts should use an ExecBase pointer and infact on OS4 Exec does pass this pointer to the code, so there is no need to read $4 there. And the start function in an OS4 program should also contain an ExecBase pointer. Well should, but examples of custom start code tend to fetch it from $4.

Quote:

Today we dont have chip ram anymore and this problem is gone.

Given that the 68K VBR would have already existed when the Amiga came out I don't know why they locked that location in. Apart from that it is a 68K reset vector location so a pretty dangerous place to stick a major pointer! Even if it isn't wiped after reset.

@Hypex

Quote:

but examples of custom start code tend to fetch it from $4.

I have no idea what they do that, Execbase should be already accessable to program when started normally. But in CatwesselMK4 (cw.device) there was problem, as was not loaded the normal way, because _main() and main() was not called, and because the device was loaded trow OpenDevice(), So I simply googled and found the a hack to get it from address 4.

While the program calling OpenDevice did already have exec.library open, address of it was stored some where in the stack/or public data of the program, but symbols to this variables where not know to the device, so there was no way obtaining this from there.

Sure I might have been able to extend iorequest with few extra parameters to hold execbase, but it be a dirty hack. Because no 68k program, and no PPC program will be compatible with it.

I belive when you open a library you, you get sysbase as parameter. (don't remember, I can check UTF8.library I wrote later)

Quote:

interrupts should use an ExecBase pointer and infact on OS4 Exec does pass this pointer to the code

This interrupt service routines will be setup by driver or device, and so the execbase should already be stored in some public variable with in the library or device. There might be that some kernel module might do it because the order of libraries loaded is not know. Any how assume it really unsafe to do anything out side the device or library due that fact interrupt does not care what programs where doing when interrupt is triggered.

Well in the case of timer interrupts, the program is signaled after the interrupt has happened, so program is not handling it when its happening just few micro seconds after.

Last edited by NutsAboutAmiga on 29-Aug-2014 at 06:43 PM.
Last edited by NutsAboutAmiga on 29-Aug-2014 at 06:42 PM.
Last edited by NutsAboutAmiga on 29-Aug-2014 at 06:09 PM.
Last edited by NutsAboutAmiga on 29-Aug-2014 at 06:08 PM.

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

@Hypex

http://hyperion-entertainment.biz/index.php?option=com_content&view=article&id=65:-amigaos-40-july-2007-update-available&catid=36:amigaos-4x&Itemid=18

Quote:

I could but on AmigaOS Semaphores were provided for the same sort of purpose. And despite them changing the API (or rather the structure which looks dangerous for old ones) they work fine as far as I can tell.

I'm only using mutexs in my code, for long time now, and they work fine.

Quote:

A Mutex (with no known structure on OS4 AFAICT) must be a simpler device with a task pointer.

Just a simple APTR, what they do point to is not some thing I need to know.
The status of mutex should only be changed when I obtain and release it anyway. I should not need poke its structure.

Last edited by NutsAboutAmiga on 29-Aug-2014 at 06:30 PM.

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

@cdimauro

Quote:

The problem here is regard keeping the backward compatibility with the old apps (both 68K and PowerPC, since they are first-class applications) while introducing the SMP support.

“first-class” maybe not word I use, but you get your point across.
So what ever the “2en-class” programs do they need to follow rules of the “first-class” right.

nutch nutch wink wink
https://www.youtube.com/watch?v=ona-RhLfRfc

Last edited by NutsAboutAmiga on 29-Aug-2014 at 06:38 PM.

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

@NutsAboutAmiga

Quote:

I have no idea what they do that, Execbase should be already accessable to program when started normally. But in CatwesselMK4 (cw.device) there was problem, as was not loaded the normal way, because _main() and main() was not called, and because the device was loaded trow OpenDevice(), So I simply googled and found the a hack to get it from address 4.

There is no such thing as starting a program normally, by that I mean any section of code may loaded with LoadSeg and executed. This code cannot know the value of ExecBase / IExec as it is not linked to the LoadSeging program, unless that program goes to alot of effort (elf.library) . To do almost anything useful you need to start from Exec so it's standard practice and not a hack to load it from 0x000000004;


TBH of all the issues dicussed in this thread I don;t see why anyone would care about this one, it's protected read only access, and I can't see how it would affect multicore, you should ofcourse copy the value and not derefernce it directly for efficiency's sake.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Hypex

Quote:

Quote: Quote: True but you can use a Mutex its already forbid free. I could but on AmigaOS Semaphores were provided for the same sort of purpose. And despite them changing the API (or rather the structure which looks dangerous for old ones) they work fine as far as I can tell. As to being forbid free that is up to the OS function. It has a counter. I can think of ways to avoid forbidding but a task still has to be added to a list and that will require some sort of forbid state. A Mutex (with no known structure on OS4 AFAICT) must be a simpler device with a task pointer.

I'm not sure what you mean by API change, SignalSemaphores should now be allocated with AlloCSysObject but apart from that they remain the same. Don't confuse them with the old Message based Semaphores which never worked and were replaced long before OS4.

Semaphores are much more complex beats than mutexes. Since version 39 you can use the Procure() and Vacate() functions on them too (they were previously used on Message Semaphores) so the new mutex is not a 100% replacement, but for 90% of usage a mutex is a drop in replacement, requiring less set up.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@NutsAboutAmiga

Quote:

While the program calling OpenDevice did already have exec.library open, address of it was stored some where in the stack/or public data of the program, but symbols to this variables where not know to the device, so there was no way obtaining this from there. Sure I might have been able to extend iorequest with few extra parameters to hold execbase, but it be a dirty hack. Because no 68k program, and no PPC program will be compatible with it. I belive when you open a library you, you get sysbase as parameter. (don't remember, I can check UTF8.library I wrote later)

When devInit() or libInit() vector is called (when available) you get execbase passed in A6 register (68k) or as third parameter (other).

Handlers dont have standard init procedure and there you have to read it from AbsExecBase.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: The problem here is regard keeping the backward compatibility with the old apps (both 68K and PowerPC, since they are first-class applications) while introducing the SMP support. “first-class” maybe not word I use, but you get your point across. So what ever the “2en-class” programs do they need to follow rules of the “first-class” right. nutch nutch wink wink https://www.youtube.com/watch?v=ona-RhLfRfc

Sorry, I'm on vacation and only with my (old) smartphone, so I cannot watch the video.

First class means that, as itix have written previously, a 68K app is threated the same as a PowerPC app. So, same rights and same contraints.

@Hypex

Initially the Kickstart ROM is at location $0 and the ChipRAM is not visible to the CPU until a switch is tapped on the Custom Chipset during intial testing,

and the initial 2 values of the reset vector are for switching from the ChipRAM location to a fixed entrypoint in the Kickstart ROM to switch ChipRAM into place and stop mirroring Kickstart at the bottom of memory.

This is what I understand of why the reset vector and AbsExecBase reference pointers share the same physical address in memory.

Again...this is in Dave Haynies archive of notes...if anyone cares to look it up.

@NutsAboutAmiga


{Quote:

Sure I might have been able to extend iorequest with few extra parameters to hold execbase, but it be a dirty hack. Because no 68k program, and no PPC program will be compatible with it.

If it is also a native PPC device then it needs an interface so you could store it there anyway.

Also the IDLTool generated this for a library. But A device wouldn't work like this.

/* The ROMTAG Init Function */
STATIC struct Library *libInit(struct Library *LibraryBase, APTR seglist, struct Interface *exec)

Quote:

This interrupt service routines will be setup by driver or device, and so the execbase should already be stored in some public variable with in the library or device.

A PPC interrupt is given ExecBase as a parameter like so:

uint32 trapCode(struct ExceptionContext *ctx, struct ExecBase *SysBase,
APTR userData)

Quote:

I'm only using mutexs in my code, for long time now, and they work fine.

I've used Semaphores on 68K and only found out about Mutexes recently on PPC.

Last edited by Hypex on 30-Aug-2014 at 04:54 PM.
Last edited by Hypex on 30-Aug-2014 at 04:47 PM.

@cdimauro

Quote:

Sorry, I'm on vacation and only with my (old) smartphone, so I cannot watch the video

Don't worry about it, it was Monty Phyton video about reading between the lines.

Quote:

First class means that, as itix have written previously, a 68K app is threated the same as a PowerPC app. So, same rights and same contraints.

I don't agree with that nescessarily. I belive itix was giving examples of 68k programs using macros that will access some counter or some thing else like that. But what if the powerpc programs where compiled with functions that replaces this macros, that are thread safe. Then same will not apply to PPC programs as it does to 68k program.

Even if some one wrote the same code and compiled it for 68k and PPC, there might be differences because SDK is newer.

There are also other things that will be different, like the use of atomic opcode, well the PowerPC does not have the same opcodes different CPU type, and most PowerPC programs are written in C, and OS provided ways to make things thread safe. The use of atomic opcodes does not really apply.

Even more PowerPC programs does need to do the same thing as 68k programs that when calling a function, 68k programs entry point is the JMP table, the PowerPC entry point is Interface table.
This also means that a 68k program and PowerPC program written in C can look the same but do different things.

Then there is the other issue that PowerPC programs 68k program run in the same enviroment there for they most be threated the same, true but ask your self how many 68k program will not work with patched installed in AmigaOS3.x, how many 68k program do not access the JMP table, but hack the Execbase or does some thing illegal. Sure there are program that stops working when installing patches, but they are not that many to begin with I think.

And then are programs with special needs like scout and other programs that collect information about the operating system, most likely this do this while using forbid() and permit(), to walk the List structures. So they should actually work I think. And even in scout breaks, so what we have other programs that can do the same, so not a big issue can't use that program anymore.

Your looking at the first floor (first class), when you should be looking at the building.
The question really is how can I build API's that programs running on the 2en core, will be able to interact with programs already running on the first core, while being thread safe. This all programs running on the 2en core has to do.

This what I mean when say that you need to do is write new guide lines that developers will need to follow to make there programs, libraries and devices SMP fremdly. In any case some programs might even be SMP fremdly already, with out adding additional API's.

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

@broadblues

Quote:

I'm not sure what you mean by API change,

Changing a Semaphore to a Signal Semaphore in the Procure() and Vacate() functions. The structures are different. Though there must be be checks to determine what the caller has passed otherwise it could crash. Which would be a violation of the Amiga library guidelines, that is a non-backward compatible library.

Quote:

Don't confuse them with the old Message based Semaphores

That's exactly what I'm tallking about. As you can see.

Quote:

Semaphores are much more complex beats than mutexes.

I don't know exacly all the features they provide, but for my purposes of needing to lock a structure to one task, a muxex should suffice fine.

@Hypex

Quote:

Also the IDLTool generated this for a library. But A device wouldn't work like this.

I did not use IDLTool I found some really old examples on the internet some where using google, I did not figure our how generate devices with IDLTools.

Quote:

A PPC interrupt is given ExecBase as a parameter like so:

Thats how MMU trap routines are setup on the OS level, there are other interrupts in the OS as well. On the lowest levels, there is interrupt vector table, where you can only provide a address to interrupt routine.

Quote:

I've used Semaphores on 68K and only found out about Mutexes recently on PPC.

Well I did not code C on 680x0 I coded in BlizBasic2 and AMOS, so C coding was some started doing on AmigaOS4 in 2004, well I coded C on Micro processor at school in 1998/1999 and wrote some C code on Linux.

So I often look up things up thing while I'm coding, I also try keep my eyes on new stuff.

Last edited by NutsAboutAmiga on 30-Aug-2014 at 07:07 PM.
Last edited by NutsAboutAmiga on 30-Aug-2014 at 05:34 PM.

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

@Hypex

Quote:

Changing a Semaphore to a Signal Semaphore in the Procure() and Vacate() functions. The structures are different. Though there must be be checks to determine what the caller has passed otherwise it could crash. Which would be a violation of the Amiga library guidelines, that is a non-backward compatible library.

I doubt there is any check, not sure how you could, and Message Semaphores are not support *at all* since 3.0 and I think depricated for 2.04 but I might be wrong about that, long time ago!

So any old 1.3 software using them would break, it was broken anyway as they didn't work.

And this change was made in OS 3.0 BTW so there not going to be much relavent software using old message semaphores.


Quote:

Quote: Quote: Semaphores are much more complex beats than mutexes. I don't know exacly all the features they provide, but for my purposes of needing to lock a structure to one task, a muxex should suffice fine.

Most of the time I'd think that was true, it woud nice to know what the exceptions were, when you should still use semaphores, unless it's only the Procure() Vacate() functionailty, which I myself have never used.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad