At 01:48 -0500 1/3/04, Uri Guttman wrote:
>>>>> "NS" == Nigel Sandever <[EMAIL PROTECTED]> writes: NS> All that is required to protect an object from corruption through NS> concurrent access and state change is to prevent two (or more) VMs NS> trying to access the same object simultaneously. In order for the VM to NS> address the PMC and must load it into a VM register, it must know where NS> it is. Ie. It must have a pointer. It can use this pointer to access NS> the PMC with a Bit Test and Set operation. (x86 BTS) NS> [http://www.itis.mn.it/linux/quarta/x86/bts.htm] This is a CPU atomic NS> operation. This occurs before the VM enters the VM operations critical NS> section. ding! ding! ding! you just brought in a cpu specific instruction which is not guaranteed to be on any other arch. in fact many have such a beast but again, it is not accessible from c.
I just _can't_ believe I'm hearing this. So what if it's not accessible from C? Could we just not build a little C-program that would create a small in whatever loadable library? Or have a post-processing run through the binary image inserting the right machine instructions in the right places? Not being from a *nix background, but more from a MS-DOS background, I've been used to inserting architecture specific machine codes from higher level languages into executable streams since 1983! Don't tell me that's not "done" anymore? ;-)
.. and still some archs don't have it so it has to be emulated by dijkstra's algorithm. and that requires two counters and a little chunk of code.
Well, I guess those architectures will have to live with that. If that's what it takes?
you can't bring x86 centrism into this. the fact that redmond/intel threads can make use of this instruction to do 'critical sections' is a major point why it is bad for a portable system with many architectures to be supported.
I disagree. I'm not a redmond fan, so I agree with a lot of your _sentiment_, but you should also realize that a _lot_ of intel hardware is running Linux. Heck, even some Solarises run on it.
I'm not saying that the intel CPU's are superior to others. They're probably not. But it's just as with cars: most of the cars get people from A to B. They're not all Maserati's. Or Rolls Royce's. Most of them are Volkswagen, Fiat and whatever compacts you guys drive in the States. ;-)
I don't think we're making Parrot to run well on Maserati's and Rolls Royce's only. We want to reach the Volkswagens. And not even today's Volkswagens: by the time Perl 6 comes around, CPU's will have doubled in power yet _again_!
The portability is in Parrot itself: not by using the lowest common denominator of C runtime systems out there _today_! It will take a lot of trouble to create a system that will run everywhere, but that's just it what makes it worthwhile. Not that it offers the same limited capabilities on all systems!
i am well aware about test/set and atomic instructions. my point in my previous reply was that it can't be assumed to be on a particular arch. so it has to be assumed to be on none and it needs a pure software solution. sure a platform specific macro/assembler lib could be done but that is a pain as well.
Indeed. A pain, probably. Maybe not so much. I can't believe that Sparc processors are so badly designed that they don't offer something similar as what Nigel suggested for Intel platforms.
again, intel specific and it has to be tossed out.
Again, I think you're thinking too much inside the non-Wintel box. You stated yourself just now "...in fact many have such beast...", so maybe it should first be investigated which platforms do suppport this and which don't, and then decide whether it is a good idea or an idea to be tossed?
virtual ram is what counts on unix. you can't request some large amount without using real swap space. it may not allocate real ram until later (page faulting on demand) but it is swap space that counts. it is used up as soon as you allocate it.
So, maybe a wrapper is, either for *nix, or for Win32, or maybe both.
what win32 does is not portable and not useful at a VM level. kernels and their threads can work well together. portable VMs and their threads are another beast that can't rely on a particular architecture instruction or kernel feature.
This sounds too much like dogma to me. Why? Isn't Parrot about borgifying all good things from all OS's and VM's, now and in the future? ;-)
hardware is tossed out with portable VM design. we have a user space process written in c with a VM and VM threads that are to be based on kernel threads. the locking issues for shared objects is the toughest nut to crack right now. there is no simple or fast solution to this given the known contraints. intel/redmond specific solutions are not applicable (though we can learn from them).
Then please lets. Instead of tossing them without further investigation.
ok, i can see where you got the test/set and yield stuff from now. fibres seem to be manually scheduled threads. this means user code has to decide to yield to another thread blocking on the same lock. this means all locks must have a list of threads/fibres blocking on that lock. and manually scheduled stuff is not appropriate for parrot. finally, it is redmond specific again and very unportable. i have never heard of this fibre concept on any unix flavor.
It's never too late. Maybe Parrot can learn from it.
and that is not possible on other platforms. also it means parrot would have to have its own scheduler with that the pain that brings.
Ah, but the joy when it _does_ come together! ;-)
your ideas make sense but only on redmond/intel which is not the target space for parrot.
Wouldn't that need to read "Intel", and therefore include most of Linuxes running out there? Are we talking CPU specific or OS specific here? If OS specific, but still on Intel, it still is some set of machine instructions at some level that could be borgified. Don't tell me Redmond has the monopoly on using some of the Intel x86 machine instructions?
Liz
