@Kronos

Ah. "We don't know what's really going on in there so we'll just assume I'm right"

See, there's this other SMP-capable OS called Linux, it's open source so we *can* tell what's going on in there. I can tell you (and you can verify) that there's no sandboxing going on. All programs run on the metal, regardless of how many CPUs you've got.

Adapting Forbid/Permit is not as big a problem as you may think. There is a very simple solution, which is for Forbid to stop task switching across all CPUs. This would be 100% backwards compatible, and it is simple to implement. It's not completely efficient, but:

1. This would only happen when running old software, new software would use a different technique than Forbid/Permit
2. It would only affect one other task (the one running at the time on the other CPU) and only if that task were not already waiting for IO to complete.

Another reasonable approach would be to run OS code in one core (devices, handlers, etc) and user code in the other one. No Forbid problem, no evil

@Jorge

First, about Cg: Cg has largely been superceded by GLSL (and it's DirectX counterpart). I'd suggest that you look into GLSL.

Quote:

What makes you think that? The only limitation is Fobid()/Permit(). But that does not mean, it will not work at all. It only means, it will stall all cores instead of only one. This is a requirement anyway if you do e.g. memtransfers (incl. DMA) with multiple sources/destination (say you write io buffers with DMA but have multiple threads doing a line decoding - all threads need to stall when you fill the buffer). This is no different to say with one core. In that case the only core available will stall. The difference is, because of the assumption, AmigaOS had one core only, Forbid()/Permit() has been used in various places where semaphores or mutexes would have been a better solution. The conclusion ? It would still run, but not as efficient as it could. Would it be slower then on a single core ? I doubt this, except stalling all cpus introduces an additional overhead compared to stalling one core only (but usually, that's not the case, is it?). The fact that AmigaOS uses shared memory for its signaling and message passing OTHO makes it a perfect candidate for multiple cores. Would be interesting to see what happens if a thread on one core crashes and how this would affect the other cores (e.g.illage op code exception on multiple cores).

Yes it would still run, and it would be slower than it should, because Forbid()/permit() will stall all cores. It will still be faster than a single core, but nowhere near as fast as it could be. The Forbid()/Permit semantics need to go. Unfortunately a lot of Amiga OS code read OS structures directly, hence the need for forbid/permit. The only solution I can think of would be to run old code in a sandbox and provide a new API for new apps.

Hans

Last edited by Hans on 06-May-2007 at 06:33 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@hatschi

That is of course the big unknown. I'll be very upset indeed if after all this, it all goes to naught because of a license dispute.

@ackcontrols

IMHO, new users of AOS4 like me would like:

- Using AOS4 from HYPERION.
- Using a hardware like AONE (but more modern technically than AONE) with cpu around 1-1.2 GHZ but with a good prize (for low money user).

OR

- Using a hardware like SAM or the low level allready announced.

OR

- Using a high end Amiga like the next announcement tomorow (like me). The high end amiga is just too beautifull and powerfull and that give to us the dream come true.

But the problem for me is AINC against HYPERION lawsuit. IMHO, during this problem, no AOS4 for the new hardware. It's impossible for me to have AOS4 during the lawsuit and that made me

thanks to discuss with all here, ack.

Last edited by Mrodfr on 06-May-2007 at 06:40 PM.
Last edited by Mrodfr on 06-May-2007 at 06:39 PM.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@CodeSmith

Now it's getting funny isn't it .......

Linux has full MP and probraly full SMP for 15 years min, and when it was started it was based on concepts found in UNIX which allready was SMP way back in the 80s......


If SMP in AOS would be so easy don't you think someone would have added (or atleast tried to) to add to AROS ? And remeber these guys don't have to bother much with compabiltiy.

Now offcourse one could create new APIs, but what is the point of OS4 if for useing it full capacity I have to avoid all old apps ? Yeap thats why sandboxing is such a good idea.

Putting devices&co on the 2nd core won't change anything, these are normal code too and must communicate by the same means than tasks between eachother.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

The structures of AmigaOS on the other hand haven't been really updated eversince 1985.

That just shows, how future proof the concept was back then.

Quote:

Rememeber how the PPC-port was supposed to be "just a matter of a compiler switch" and how hard it really turned out ?

I don't know what that has to do with multi core. There was simply a lot work necessary to allow 68K traps and exception to work in a ppc only environment -incl. full transparency into ppc traps, irqs and exceptions. This was an amazing job, BTW. We are talking about two totally different physical entities which now work completely transparent to the application.

Quote:

Adapting Forbid/Permit (and more important what happens in between those 2) may sound easy, but getting all details, sideefects and quirks right to allow reasonable compability might turn out a nightmare.

No doubt it will. Especially running multicore will magnify (I use Codesmith's term here) multithreading race conditions to some degree, on two cores, the frequency of Forbit()Permit() will simply double, an linear proportional with the number of cores. Sure, we won't know unless it runs on multiple cores (did anybody actually try this on the Dual G4 board for the XE ? - I know it exists and is/was running).
Nobody denies, there is some work necessary, but - say - its easier then to port the whole OS to a little endian machine.

Quote:

Reasonable approach would be sandboxing the whole shebang and only allow new SW to run on the 2nd core, but that thought is pure evil as we all know

This is silly. Define a sandbox. Just because this is so much further away doesn't solve the problem. No work, research or anything else has been done on sandboxing AmigaOS except UAE (in a 3.x environment). Let alone the interfacing between the sandbox and the core OS needs to be defined in the first place. You throw a buzzword and make it sound simple. Even a sandbox is no trivial task.

BTW: Compared to these things what's much more important is a new graphics kernel in the OS which allows to use state of the art HW acceleration. This is a much more serious issue then multi core, simply because this needs a complete new and fresh approach (I don't think using a DRI/OpenGL on the backend will solve the problem, though). The graphics.library (and all p96/cgx stuff with it) has to go (but might survive as a wrapper).

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@Kronos

Quote:

Linux has full MP and probraly full SMP for 15 years min, and when it was started it was based on concepts found in UNIX which allready was SMP way back in the 80s......

Ah, no. From the Linux SMP Howto: "Linux works on SMP (Symmetric Multi-Processors) machines. SMP support was introduced with kernel version 2.0, and has improved steadily ever since."

Quote:

If SMP in AOS would be so easy don't you think someone would have added (or atleast tried to) to add to AROS ? And remeber these guys don't have to bother much with compabiltiy.

I wouldn't know, I'm not an AROS core dev. If I had to hazard a guess, they wanted to get other stuff working first; the AROS team is rather small and SMP is only starting to become popular now.

Quote:

Now offcourse one could create new APIs, but what is the point of OS4 if for useing it full capacity I have to avoid all old apps ? Yeap thats why sandboxing is such a good idea.

OS4 would not have to avoid old apps. It could do something like deprecate the use of Forbid in favour of semaphores, and you'd have the backwards compatible way of doing things, which happens to slow things down, and the new way which does not. Coders would be motivated to use the new way, so eventually the problem would go away as replacements are written for old apps (PenPal or AbiWord? Hmmm...)

@Hans

:

Well, for the Amiga, whatever shader language you'd choose, there's nothing available (or even possible) at this point.

Quote:

Yes it would still run, and it would be slower than it should, because Forbid()/permit() will stall all cores. It will still be faster than a single core, but nowhere near as fast as it could be. The Forbid()/Permit semantics need to go. Unfortunately a lot of Amiga OS code read OS structures directly, hence the need for forbid/permit. The only solution I can think of would be to run old code in a sandbox and provide a new API for new apps.

Can we agree, that we should start to walk before we begin to run ? Currently Amiga is crawling. Getting OS4 on a multicore - even without optimal performance - could prepare the next step (which probably won't be OS4 any more). We have a chicken and egg problem here. Seems the HW will come, an OS can be made available for it, everything else will take another 2+ years anyway. In that time, people can play OS4, some might even be able to make some money. How long do you want to wait to make another version of AmigaOS ? Add some more features and delay it another 2 years ?

On a side note. I hear the "system access data structures directly hence the need to use Forbid()/Permit()". Well, maybe someone can explain to me, why this implies a requirement to use Forbit()/Permit(). The only need for it is, because there is no other way for an atomic lock (AFAIS) and has more to do with IRQs and scheduling rather then accessing data structure. At a certain point you gotta do that - and usually semphores (or critical locks or whatever you want to call them) are necessary. An API in between just gives you a clear border, but does not change the mechanism.

Last edited by Jorge on 06-May-2007 at 07:11 PM.

_________________
AmigaOne XE G3/933/VIA/FM801/R200 (fixed),
G3SE/600/Voodoo3/Sil680/RTL8139/SBLive! (noiseless!)
µA1-MK2/G3/933/R200/CMI8738
XE/G4 (broken 7450/800)

@Mrodfr

Quote:

But the problem for me is AINC against HYPERION lawsuit. IMHO, during this problem, no AOS4 for the new hardware. It's impossible for me to have AOS4 during the lawsuit and that made me

The entry-level "design" is announced for "Summer 2007". We'll see what happens and how Amiga Inc will miraculously get *legal* rights to *all* required sources to that date.

@Jorge

Exactly. SMP is a hardware feature, so the hardware has no choice but to come first. Even if OS4 uses only one of the two cores, I will know that I can upgrade to an SMP capable version of it when it gets released.

@hatschi

Quote:

Somewhere I read "end of 2007

Hmmm....

http://www.theinquirer.net/default.aspx?article=37426
http://www.pasemi.com/news/pr_2007_03_20.html

Looks like samples are on offer at the moment. Maybe extremely late summer or they get them out earlier than expected....

Last edited by debrun on 06-May-2007 at 07:03 PM.

_________________
If you're going through hell, keep going. -Winston Churchill

@Jorge

Quote:

Jorge wrote: @Hans : Well, for the Amiga, whatever shader language you'd choose, there's nothing available (or even possible) at this point.

True. The Friedens said that a MESA implementation would come once a new graphics system was in place. This should include GLSL. My point was that GLSL is a better choice than Cg.

Quote:

Can we agree, that we should start to walk before we begin to run ? Currently Amiga is crawling. Getting OS4 on a multicore - even without optimal performance - could prepare the next step (which probably won't be OS4 any more). We have a chicken and egg problem here. Seems the HW will come, an OS can be made available for it, everything else will take another 2+ years anyway. In that time, people can play OS4, some might even be able to make some money. How long do you want to wait to make another version of AmigaOS ? Add some more features and delay it another 2 years ?

I'd be perfectly happy if forbid/permit initially stalled both CPUs. It's a temporary step. They can improve things step by step.

Hans

Last edited by Hans on 06-May-2007 at 07:26 PM.
Last edited by Hans on 06-May-2007 at 07:03 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@debrun

Remember also that the initial market for these boards is going to be just a few hundred. That could well fit into the "samples" volume, since "full production" volume for chips usually means millions.

Right now I'm more worried about the licensing lawsuit though.

@Kronos

Don't bother, they *don't want* to understand...

@takemehomegrandma

I guess that means that every time anything goes wrong with OS4, we can count on you two to come tell us it's because of SMP and Forbid?

@CodeSmith

Quote:

You're falling into the familiar trap of comparing artificial benchmarks across cpu architectures. PPC and x86 instruction sets are so different that the only benchmarks that really count are wall-clock ones. I'd like to see comparisons of say the time it takes to do a ray trace, or to encode a certain piece of music into MP3. Then we can do meaningful comparisons.

SpecInt scores are all we have to go on right now for the PA Semi chip, which possibly isn't a good sign. Manufactuers of high performing chips usually scream as many benchmark results as possible, as loudly as possible.

But, yes, I agree. Results from more real-world tests would be much more informative.

Quote:

Wide range available? There are just a handful of NB chips than can talk Hypertransport, and in any case you're constrained by the 2000MT/s bandwidth so you can't just keep adding peripherals. The description of PCI express support is a bit confusing, but it sounds like you get what most x86 NBs give you: 1x16 and a few more lanes split between x8, x4, x2 and x1. Sure, you don't get 2x16 Crossfire support, but I think only one NB from NVidia supports that.

There's a ton of hypertransport system chips out there. I could name 20 of them just from memory. Bandwidth issue are not a problem with HT because you simply hang a second system controller chip from another HT link (Opterons have up to 3 HT links, for example). This is how NVidia's 'server/workstation' chipsets work, they're really just two desktop syscontroller chips working in tandem.

I must confess, I don't really understand how the 1682 handles PCIe. It seems to have 24 'serial lanes', some of which are used by on-board devices like the ethernet controllers, with the others being available for PCIe use. It's an interesting and potentially very flexible system, but I've seen references to an upper limit of 8 PCIe lanes which would be rather less than optimal.

_________________
Who do you serve, and who do you trust? - Galen

@Hans

Quote:

Yes it would still run, and it would be slower than it should, because Forbid()/permit() will stall all cores.

And what about SysBase->ThisTask ?

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

@DrBombcrater

Fair enough, but you have to admit that the vast majority of consumer boards use only one HT link. I'm not sure how well the 1682 would do in a server environment, too many questions are unanswered. I still think it would make a pretty slick workstation, the requirements are much lower there.


@Kronos, takemehomegrandma

Read DrBombcrater's post, this is how one argues his point. Facts and logical deduction, not innuendo and condescention.

@itix

Quote:

itix wrote: @Hans Quote: Yes it would still run, and it would be slower than it should, because Forbid()/permit() will stall all cores. And what about SysBase->ThisTask ?

Were people ever supposed to read that directly?

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@CodeSmith

There are two ways of obtaining things like real SMP and real memory protection

1) Kiss all bakwards compatibility (I'd like to call that *Amiga* compatibility) and Amiga applications goodbye, create a *new* OS based on modern concepts (why not throw in multi-user support as well when you are at it, and a POSIX layer, for easy porting of modern applications like browsers, office programs, etc), and call that OS "AmigaOS" instead of what we all know and recognize as Amiga today.

(But since it won't be Amiga anymore, other than by the name, why bother in the first place? Why not simply use one of the OS's that already have all these features, and have a huge stack of modern applications as well, instead of beginning to climb the first steps on a stairway at the height of Mount Everest?)

2) Sandbox the Amiga envireonment altogether in order to keep it as Amiga compatible as possible, and run all "modern" features outside of that box, and simply accept that whatever is *inside* the box won't ever benefit from those OS features.

(But wouldn't that be like ... MorphOS? (Quick now: spit-spit-spit, salt over the shoulder, ten Ave-Maria!))