Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Java versus C Speed Comparison

Author: Matt Taylor

Date: 10:49:28 01/12/03

Go up one level in this thread


On January 12, 2003 at 02:13:57, Miguel A. Ballicora wrote:

>On January 11, 2003 at 19:26:43, Robert Hyatt wrote:
>
>>On January 11, 2003 at 16:44:26, Miguel A. Ballicora wrote:
>>
>>>On January 11, 2003 at 11:40:00, Robert Hyatt wrote:
>>>
>>>>What do you suppose will happen when we have 64 bit machines with 128 bit
>>>>integers?  Care to guess what that will do to portability when you try to
>>>>send binary files around between a 32 bit and a 64 bit architecture?  Then
>>>>you might begin to see _the_ problem with the data types as they exist.
>>>
>>>To send binary files portably you have to do it byte by byte, so it is the same
>>>no matter what system you use. You cannot send an int32 as a block, that is not
>>>portable at all no matter what system you use.
>>
>>Sure it is.  It is only non-portable on machines with different endianess.
>
>It is not portable on machines with different endianess, so sure it is not
>portable.

Standard BSD sockets resolve this grievance quite nicely.

>>But even with that, if I write an "int" how many bytes do I write?
>
>If you make it portable, you can't write an int and you can't write int32_t
>either. You have to write it byte by byte.

See above. You can write an int32 just fine. You can't write an int, however.

>>>>>Even if you want something very specific you can use unsigned bitfields so they
>>>>>will wrap after 12, 17 or whatever bits you want. Generally using the 'and' is
>>>>>so simple that it doesn't justify to be bothered.
>>>>
>>>>
>>>>Sorry but that is wrong.  Bitfields are not well-defined in the standard.
>>>>Which end do they start from?  You instantly see the problem with using them.
>>>>And trying to put them into a structure adds a random amount of padding,
>>>>the random amount being the unused bits in a native "thing" the compiler has
>>>>to use, which is yet another problem.
>>>
>>>It does not matter if you use one bitfield per structure just to use a number
>>>with "x bits" if you really want that number defined in that way.
>>>
>>>Miguel
>>
>>Doesn't matter which end of a word a bit field starts on?  Doesn't matter which
>>order the bitfield variables appear in?  To an operating systems person it
>>matters a _bunch_ because the definitions for O/S tables are pre-defined and I
>>just want to access them.  And I can't...
>
>That is using bitfields to match bits, which is not portable. It is not what I
>said. Anyway it is not critical for the discussion because as I said before, it
>is preferred to use the classical way for bits manipulation (& >> etc.), and the
>bitfield can be used only as ints or (hence, portable only up to 16 bits).

So because someone screwed up in their specification we're not allowed to
express a perfectly legitimate programming construct?

Further, on machines with larger integers, packed bitfields are impossible.

This also makes it impossible to write a portable machine emulator in C.

-Matt



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.