View mode: basic / threaded / horizontal-split · Log in · Help
August 22, 2003
Typesize
Pardon my layout or wrong posting. My news-server don't subscribe to comp.land.d
(which i after much investigation from the C-lang homepage figured out to be the
news-group). So please reply to my mail-address as well as the newsgroup.

I tried to read the archive to get an answer to my question but couldn't find
any.

Anyway, I been woundering about integer sizes on different architectures. The
D-lang specifies all integer types as hard defined being of a certain bit-size.
However different CPUs has different favourite sizes and are different fast/slow
when a size that doesn't fit them comes around. For example 64bit alpha vs.
32bit x86. I see no type for "compilers choise". Loop-iterators could use this
type for an obivous example. The type "Any bit-size (but aleast say 16bits) that
the hardware and compiler figures to be the fastest for the case.". 

Or perhaps if the compiler can figure out that the "int" (32bit) I used in my
program that I compile for a 64bit target architecture can be swaped out for a
long (64bit), as long as it's a local variable or a function call/return
variable and is not in a struct where it might must fit any header and be of
exactly 32bits. This might be a better case and we don't have to make another
type. It just needs to be documented better if so.

Please include my mailadress gozem@aaricia.csbnet.se in a reply. Thank you. 



/Joakim Axelsson
August 23, 2003
Re: Typesize
<gozem@aaricia.csbnet.se> wrote in message
news:bi67cm$2cut$1@digitaldaemon.com...
> Anyway, I been woundering about integer sizes on different architectures.
The
> D-lang specifies all integer types as hard defined being of a certain
bit-size.
> However different CPUs has different favourite sizes and are different
fast/slow
> when a size that doesn't fit them comes around. For example 64bit alpha
vs.
> 32bit x86. I see no type for "compilers choise". Loop-iterators could use
this
> type for an obivous example. The type "Any bit-size (but aleast say
16bits) that
> the hardware and compiler figures to be the fastest for the case.".
>
first: having fixed sizes for int is good, you know what your going to get
on all platforms.
second: I would hope that the D compiler is smart enough to use the right
semantics for locals and params and the right sizes for structs.

loop iterations would be better if the language had the syntax to tell the
compiler I want to loop N times so it could unwind.
having a type that is at least N bits means that you run the risk of code
behaving different arch's


there is no reason that an int (32 bit) can not be passed or stored in a 64
bit register or stack slot/param
as long as all operations appear to be at the correct bit length;
and its only realy compare where there may be an issue and even then only on
risc arch's
68K and x86 can compare 8,16, 32 bit values.
Arm for instance can only compare 32 bit values, so 8 or 16 bit compares
have to "normalise" the operands first (on arm thats just one extra
instruction if only one value need adjusting three if both)
[see below]
so its no great overhead. for the safety that you know no matter what
hardware you will get the same results (overflow bugs and all) and on a cpu
with 2 or more pipelines than the chances are that the adjustment can be
paired with the other calculation or loading of const etc.


if ( a < (b+c) ) {... }
ldrsh r0, [sp, 8]  //get a sigh halfword (16 bit from the stack)
ldrsh r1, [sp, 12] // b
ldrsh r2, [sp, 16] // c //assume unpacked shorts
add r1, r1, r2  // might over flow
mov r1, r1 lsl 16 // shift 16 bits left '0's in
cmp r0, r1, asr 16  // compare r0 (which is right as its unmodified since
loading)
                            // with r1 shifted (sign extened) left.
bge not_this_time

if ( (a+d) < (b+c) ) {... }
ldrsh r0, [sp, 8]  //get a sigh halfword (16 bit from the stack)
ldrsh r1, [sp, 20] // d
add r0, r0, r1   // might overflow
ldrsh r1, [sp, 12] // b
ldrsh r2, [sp, 16] // c //assume unpacked shorts
add r1, r1, r2  // might over flow
mov r0, r0 lsl 16 // shift 16 bits left '0's in
mov r0, r0 asr 16 // shift 16 bits right sign extended
mov r1, r1 lsl 16 // shift 16 bits left '0's in
cmp r0, r1, asr 16  // compare r0 (which is right as its unmodified since
loading)
                            // with r1 shifted (sign extened) left.
bge not_this_time

if the arm had load delay slots like mips does then this code could be
changed to
ldrsh r0, [sp, 8]  //get a sigh halfword (16 bit from the stack)
ldrsh r1, [sp, 20] // d
add r0, r0, r1   // might overflow
ldrsh r3, [sp, 12] // b
mov r0, r0 lsl 16 // shift 16 bits left '0's in
ldrsh r2, [sp, 16] // c //assume unpacked shorts
mov r0, r0 asr 16 // shift 16 bits right sign extended
add r3, r3, r2  // might over flow
mov r1, r3 lsl 16 // shift 16 bits left '0's in
cmp r0, r1, asr 16  // compare r0 (which is right as its unmodified since
loading)
                            // with r1 shifted (sign extened) left.
bge not_this_time
August 23, 2003
Re: Typesize
In article <bi6hdc$2rpa$1@digitaldaemon.com>, Mike Wynn says...
>
>
><gozem@aaricia.csbnet.se> wrote in message
>news:bi67cm$2cut$1@digitaldaemon.com...
>> Anyway, I been woundering about integer sizes on different architectures.
>The
>> D-lang specifies all integer types as hard defined being of a certain
>bit-size.
>> However different CPUs has different favourite sizes and are different
>fast/slow
>> when a size that doesn't fit them comes around. For example 64bit alpha
>vs.
>> 32bit x86. I see no type for "compilers choise". Loop-iterators could use
>this
>> type for an obivous example. The type "Any bit-size (but aleast say
>16bits) that
>> the hardware and compiler figures to be the fastest for the case.".
>>
>first: having fixed sizes for int is good, you know what your going to get
>on all platforms.
>second: I would hope that the D compiler is smart enough to use the right
>semantics for locals and params and the right sizes for structs.
>
>loop iterations would be better if the language had the syntax to tell the
>compiler I want to loop N times so it could unwind.
>having a type that is at least N bits means that you run the risk of code
>behaving different arch's
>
>
>there is no reason that an int (32 bit) can not be passed or stored in a 64
>bit register or stack slot/param
>as long as all operations appear to be at the correct bit length;
>and its only realy compare where there may be an issue and even then only on
>risc arch's
>68K and x86 can compare 8,16, 32 bit values.
>Arm for instance can only compare 32 bit values, so 8 or 16 bit compares
>have to "normalise" the operands first (on arm thats just one extra
>instruction if only one value need adjusting three if both)
>[see below]
>so its no great overhead. for the safety that you know no matter what
>hardware you will get the same results (overflow bugs and all) and on a cpu
>with 2 or more pipelines than the chances are that the adjustment can be
>paired with the other calculation or loading of const etc.
>

So this means in practice that in D I should always use the smallest possible
integer size type for my local variabels and function params? The compiler will
make the fastest possible code of it anyways.

This ofcouse does not apply for structs/variables holding data in "memory" only
variables that compiler surly will assign to registers and stack.

Or am i wrong here in any other sence?



/Joakim Axelsson, gozem@aaricia.csbnet.se
August 23, 2003
Re: Typesize
I think that one thing that needs to happen is that if you ask for a type
and it's not available on that platform, it's ok for the language
implementor to use a slightly larger number of bits.

The portability thing isn't so much of an issue these days, since almost
everyone has universally standardized on powers of two for register sizes.

I wouldn't be against having a "machine native word" type.  You could in
fact call it "word".

D has bit, byte, char, wchar, short, int, long, cent.

On 32 bit machines, word would be same as int, and on 64 bit machines word
might be same as long.  On wierd 42-bit machine, word would be 42 bits.  ;)

I wouldn't mind standardizing on some names like sint8, sint16, uint32,
uint64, because 90% of all projects have those kind of typedefs.

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message
news:bi6hdc$2rpa$1@digitaldaemon.com...
>
> <gozem@aaricia.csbnet.se> wrote in message
> news:bi67cm$2cut$1@digitaldaemon.com...
> > Anyway, I been woundering about integer sizes on different
architectures.
> The
> > D-lang specifies all integer types as hard defined being of a certain
> bit-size.
> > However different CPUs has different favourite sizes and are different
> fast/slow
> > when a size that doesn't fit them comes around. For example 64bit alpha
> vs.
> > 32bit x86. I see no type for "compilers choise". Loop-iterators could
use
> this
> > type for an obivous example. The type "Any bit-size (but aleast say
> 16bits) that
> > the hardware and compiler figures to be the fastest for the case.".
> >
> first: having fixed sizes for int is good, you know what your going to get
> on all platforms.
> second: I would hope that the D compiler is smart enough to use the right
> semantics for locals and params and the right sizes for structs.
>
> loop iterations would be better if the language had the syntax to tell the
> compiler I want to loop N times so it could unwind.
> having a type that is at least N bits means that you run the risk of code
> behaving different arch's
August 23, 2003
Re: Typesize
In article <bi7a1q$165d$1@digitaldaemon.com>, Sean L. Palmer says...
>
>I think that one thing that needs to happen is that if you ask for a type
>and it's not available on that platform, it's ok for the language
>implementor to use a slightly larger number of bits.
>
>The portability thing isn't so much of an issue these days, since almost
>everyone has universally standardized on powers of two for register sizes.
>
>I wouldn't be against having a "machine native word" type.  You could in
>fact call it "word".
>
>D has bit, byte, char, wchar, short, int, long, cent.
>
>On 32 bit machines, word would be same as int, and on 64 bit machines word
>might be same as long.  On wierd 42-bit machine, word would be 42 bits.  ;)
>

This is somewhat the idea i had for a "solutions". A new type which has no
specification on its size. However it needs a guaranteed minimum size for it to
be pracitcal to use. Perhaps 16bits (or 32bits since D wont work good anyways
with sub 32bits system according to the docs). However you can't using it when
you rely upon that it will overflow at 2^32 and use the "feature" of it wraping
around since when running on an alpha this "word" will be 64bits. I think its
hard for the compiler to be able to figure out when you want to use the
"overflow feature" of a plain 32bit int and when you simply want a register in
the cpu. D was designed for speed. Its not Java. I'm fairly sure we will
otherwize see things like:

version (Alpha)
{
alias myint long
}
version (x86)
{
alias myint int
}

I dont really like the name "word". I better use the name 'reg', but might be
confusing with the (never used today) reserverd word 'register' in C/C++.


>I wouldn't mind standardizing on some names like sint8, sint16, uint32,
>uint64, because 90% of all projects have those kind of typedefs.
>

Naming the integer types (and the floating point) after its actuall bit size is
a good idea. I already have alias for them to make it more easy to understand
when i build a struct that needs to fit a binary packet (IP-headers for one easy
example).





/Joakim Axelsson
August 27, 2003
Re: Typesize
gozem@aaricia.csbnet.se wrote:

> Anyway, I been woundering about integer sizes on different architectures. The
> D-lang specifies all integer types as hard defined being of a certain bit-size.

Wrong. They are defined to be *at least* specified size - and is maent 
to (though not necessarily must) be of exactly that size on 32-bit 
architectures.

This means:
 * D is meant to be used on 32-bit machines but nothing less than that;
 * As we move on to machines with longer words, the typesystem would 
scale up accordingly - with types becoming longer. The transition plan 
for 64-bit machines is there already.

-eye
August 27, 2003
Re: Typesize
Ilya Minkov wrote:
> gozem@aaricia.csbnet.se wrote:
> 
>> Anyway, I been woundering about integer sizes on different 
>> architectures. The
>> D-lang specifies all integer types as hard defined being of a certain 
>> bit-size.
> 
> 
> Wrong. They are defined to be *at least* specified size - and is maent 
> to (though not necessarily must) be of exactly that size on 32-bit 
> architectures.

Where do you see this?  http://digitalmars.com/d/type.html seems to say 
that the types are exactly a given size, not "at least."
August 28, 2003
Re: Typesize
> Ilya Minkov wrote:
>> Wrong. They are defined to be *at least* specified size - and is maent 
>> to (though not necessarily must) be of exactly that size on 32-bit 
>> architectures.

Russ Lewis wrote:
> Where do you see this?  http://digitalmars.com/d/type.html seems to say 
> that the types are exactly a given size, not "at least."

http://www.digitalmars.com/d/portability.html
the first bullet.

-eye
August 28, 2003
Re: Typesize
In article <bi7a1q$165d$1@digitaldaemon.com>, Sean L. Palmer says...
bits.
>
>
>I wouldn't mind standardizing on some names like sint8, sint16, uint32,
>uint64, because 90% of all projects have those kind of typedefs.

C99 already standardized this why invent different names?
they are uint32_t, uint8_t, int16_t  etc
August 29, 2003
Re: Typesize
Because I've been using uint32 etc since before C99, and because no C++
compilers support C99 yet AFAIK.

Anyhow D does not have to be identical to, or even compatible with, C.
Personally I despise the "blah_t" naming convention.  Just about all C
standard library names, come to think of it.  ;)

Sean

"Mark T" <Mark_member@pathlink.com> wrote in message
news:bilkv0$2007$1@digitaldaemon.com...
> In article <bi7a1q$165d$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >I wouldn't mind standardizing on some names like sint8, sint16, uint32,
> >uint64, because 90% of all projects have those kind of typedefs.
>
> C99 already standardized this why invent different names?
> they are uint32_t, uint8_t, int16_t  etc
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home