@CodeSmith

"some changes in that direction in the new memory system" ain't the same as doing a (backward-compatible) SMP-OS.

Dunno what Visical is but if it is from 1982 it's probraly pure MsDOS meaning it doesn't know anything bout multitasking or even how to do proper OS-calls.

The DOS-window in modern Windows is more of an emulator than anything else.


Getting 2 instances of UAE running on 2 cores shouldn't be a problem, but that ain't the goal here ....

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

@takemehomegrandma

Quote:

By concept, Amiga can't be SMP. Forcing SMP into the picture will break Amiga.

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

_________________
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

OK, I'm starting to get irritated by these obtuse replies.

First, I used Visicalc as an example. How about this: I can run VB6 as well on my dual core box too. That doesn't run in a sandbox and I'm pretty certain Microsoft didn't code that with multiproc in mind. Yet somehow it works.

Second, I don't understand why you two are having so much trouble understanding SMP. THE OS IS SUPPOSED TO TAKE CARE OF IT, NOT THE APPS. The only effect that SMP has on a program that was already written to be multitasking is to magnify the effect of thread safety bugs. That's it. The OS needs changes to the syncronization functions, and to optimize certain things differently.

Jeez, I'm getting flashbacks to the times I was explaining to my friends that this computer called the amiga could really run many programs at the same time. The same sort of "I call BS" like "I call BS because you'd need one keyboard and screen per program" and "I call BS because all your timing loops would get out of whack"

Just accept it, OK? if Windows can manage SMP without breaking their legendary backwards compatibility, I'm sure we can too.

@CodeSmith

Quote:

The first one is a given, OS4 will have to be modified to manage both CPUs.

It has to be modified to run on that cpu/board anyway.

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

@takemehomegrandma
Quote:

OK, let's try with some pedagogy for two-yearolds:

thats really pathetic. if at any time you feel like actually providing some arguments instead of just behaving like an idiot please feel free.

/stone

@CodeSmith

MMmmmm SMP on x86 started with the PentiumPro (maybe earlier) which means something like mid nineties ...... Windows was sandboxed atleast one time during the Win3.x to XP transition, so it's hard to say wether old SW really runs on the metal or mor in an emulation.

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

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

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.

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

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

@stone

He's throwing a hissy fit because this is one thread he can't bring the Efika into and feel all smug about.

@dirigent

Quote:

If we can get an up-to-date machine with the ability to dual-boot OS4 and Linux for around $1500, that will be just great. I hope it can become a reality.

Yes, that's very interesting. I still would like to see some NVidea support, though. I'd like to look more into Cg, and am thinking of buying an x86 box or even a mac to play around with it. Combined with some stuff I'm doing on the PS3, that system might be a better alternative then a MacIntel. I could at least test vmx and multihreaded code on a nice dev box, and probably port or code with both, Linux and AOS in mind...(doesn't mean I shouldn't add a winbox, too, but that is not that important any more). So, yeah, I am looking forward to this system. I still have time. I won't buy anything before 2008 anyway. Hopefully until then, all this issues (technically and legally) will be resolved.

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

@Jorge

Quote:

Jorge wrote: @CodeSmith Quote: The first one is a given, OS4 will have to be modified to manage both CPUs. It has to be modified to run on that cpu/board anyway.

Indeed. The question is *how* that is gonna happen, since it would require Amiga Inc and ACK to legally get the full rights to *all* OS4 sources, including ExecSG from the Friedens.
Even if the lawsuit is ruled in the plaintiffs’ favor, I remain very sceptical about that.

Oh and what's the timeline for the PA Semi to reach volume production? Somewhere I read "end of 2007".

@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