Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: local/temporary labels in gcc inline assembly

Author: Robert Hyatt

Date: 14:17:53 12/09/02

Go up one level in this thread


On December 09, 2002 at 17:08:18, Dieter Buerssner wrote:

>On December 09, 2002 at 16:52:34, Robert Hyatt wrote:
>
>>Yep.  however, even the ANSI C committe could not agree on what to do with
>>things
>>from int, short, long and how to specify 64 bit ints...
>
>The ISO C standard defines those types IMHO in a very sensable way, by giving
>minimum allowed ranges for a conforming compiler. The C99 Standard defines
>[unsigned] long long basically as a type that has at least 64 bits.

Unfortunately C99 is not particularly well-supported yet.  The previous C
standard
left a _lot_ of holes.  Is char signed or unsigned by default?  Neither.  Which
is stupid.
Is long 16 or 32 or 64 bits?  Any of the above depending on the machine.  Do bit
fields
start right-justified or left-justified?  Either.

The list goes on...

> Any further
>specification (especially of the shorter types) would probably make it
>impossible to implement it efficiently on some architectures (for example for
>some embedded processors, which prefer int to be 16 bit and will produce faster
>code with this. Others use 32 bits even for char - they can't adress unaligned
>data. Generating code with masks etc. could make the code very inefficient).
>For most programming tasks, I see not much of a problem with the Standard
>definition of the types.
>
>If they would define the exact range of types, should they stop there? One could
>go on and ask to define an endianess.


That would suit me.  The intel little-endian approach was ok for compatibility.
It
is now a complete bit of nonsense.


>
>Regards,
>Dieter



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.