Re: QUESTIONS 2

[Jose Orlando Pereira <jop@di.uminho.pt>]

Angus Leeming wrote:
> I have had to change req_align() to do so :-(
> However, I think that the logic behind the old version was incorrect.
> (Certainly, it didn't work on the Alpha!) The new version is no bigger, so
> performance shouldn't change.

I'll look into it.
 
> _______________________________________________________________
> Ok, the questions:
> 
> There is a variable "bool endianess" in GIOP_format. What is its purpose?
>
> I THINK that it exists so that data written by one machine can be read by
> another. Is this correct?

Yes.
 
> If so, then "long" should be cast to "long long" for storage (in
> GIOP_format) ALWAYS, because long is 64 bits on some machines and 32 bits on
> others.
 
I agree. If long is 64 bits in the alpha we should make it 64 bits
everywhere in GIOP. In XDR, we probably should stick to 32 bits and
discard higher bits.

Another option is to omit defining simple(long&) to force people to
use other types.

> If this isn't its purpose, then endianess is redundant I think. (And
> consequently, all those calls to bswap_16() etc are unnecessary.)

No. In GIOP each architecture is supposed to write data using its preferred
endianess, prefixing it with a boolean stating wether the chosen format
is little or big endian. As such, every architecture is supposed to be
able to read both byte orders as appropriate.

The endianess variable is used to keep the leading prefix, in order for
decoding procedures to compare it with the native preferred endianess 
and do the needed conversion.
 
> Another, related question:
> Is GIOP_format designed to import/export between different machines whilst
> XDR_format is designed for one machine only?

No. They are both designed for distributed programming.
 
> If XDR_format is designed for possibly MANY machines then similar endianess
> functionality should be put in XDR_format. It doesn't exist currently.
> Furthermore, since the length of a word differs between machines, then the code
> should use 64 bits as its storage size ALWAYS. Same reasoning as above. Sounds
> horrible, doesn't it!!!

I don't think so. We should stick to the standard: XDR is supposed to
always be big endian. If we invent some new format that looks like XDR
but with multiple line byte orders we should separate it and give it a
different name. The same goes for 32 vs 64 bits: the standard says 32
and we should stick with it or call it something different.

> If XDR_format is designed for ONE machine only, then we can discard all that
> bswap_32() etc stuff. The internal translations don't need it. This means that
> those global functions can be sucked back into the class.

I don't think that is wise: XDR and GIOP are interoperability standards.
We don't have the option to change them.

What could be done is to make the necessary changes to raw_format in
order to make it the ideal format for in process conversion and
storage.

-- 
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *