From: Chris Thomasson on
Is everybody in this thread wrong?

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6715c3e5a73c4016

That would suck!


:O


From: Chris Thomasson on

> I gather that the "membar #LoadStore | #LoadLoad" notation means
> something in c.p.t but it is not in regular usage here.

Its from the SPARC instruction set...


From: Chris Thomasson on

"Chris Thomasson" <cristom(a)comcast.net> wrote in message
news:jP2dnQSf9uyya6PYnZ2dnUVZ_vOdnZ2d(a)comcast.com...
>
>> I gather that the "membar #LoadStore | #LoadLoad" notation means
>> something in c.p.t but it is not in regular usage here.
>
> Its from the SPARC instruction set...

You can create many different types of barriers with the SPARC membar
instruction.

RCU would not seem to work on x86 if the loads can get freely reordered..
This would make it similar to the way Alpha does things.


From: Jan Vorbr├╝ggen on
> 2) A lot of 64-bit objects need to be only 32-bit aligned, and most
> 128-bit objects need to be only 64-bit aligned.

Non-naturally aligned objects are the spawn of the devil - just say No.

Jan
From: Jan Vorbr├╝ggen on
> Exactly, WHY is it natural for a complex number to be aligned according
> to its size rather than according to the size of its real components?

It isn't, in this case. If you had a instruction in your ISA that actually
worked on a complex number as a whole, the answer would be different. But you
don't, so it's natural alignment is that of its real component.

But then, I'd rather not have Fortran definition (for some historical reasons)
that you can actually consider a complex number as a structure of two reals of
a certain defined arrangement. However, this has nothing to do with your ISA,
but at what level of abstraction a programming language should be defined.

Jan