www.digitalmars.com         C & C++   DMDScript  

D - Typesize

reply gozem aaricia.csbnet.se writes:
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
Aug 22 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
<gozem aaricia.csbnet.se> wrote in message
news:bi67cm$2cut$1 digitaldaemon.com...
 Anyway, I been woundering about integer sizes on different architectures.

 D-lang specifies all integer types as hard defined being of a certain

 However different CPUs has different favourite sizes and are different

 when a size that doesn't fit them comes around. For example 64bit alpha

 32bit x86. I see no type for "compilers choise". Loop-iterators could use

 type for an obivous example. The type "Any bit-size (but aleast say

 the hardware and compiler figures to be the fastest for the case.".

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
Aug 22 2003
next sibling parent gozem aaricia.csbnet.se writes:
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.

 D-lang specifies all integer types as hard defined being of a certain

 However different CPUs has different favourite sizes and are different

 when a size that doesn't fit them comes around. For example 64bit alpha

 32bit x86. I see no type for "compilers choise". Loop-iterators could use

 type for an obivous example. The type "Any bit-size (but aleast say

 the hardware and compiler figures to be the fastest for the case.".

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
Aug 22 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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


 The
 D-lang specifies all integer types as hard defined being of a certain

 However different CPUs has different favourite sizes and are different

 when a size that doesn't fit them comes around. For example 64bit alpha

 32bit x86. I see no type for "compilers choise". Loop-iterators could


 this
 type for an obivous example. The type "Any bit-size (but aleast say

 the hardware and compiler figures to be the fastest for the case.".

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

Aug 23 2003
next sibling parent gozem aaricia.csbnet.se writes:
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
Aug 23 2003
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
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
Aug 28 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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

Aug 29 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
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
Aug 26 2003
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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."
Aug 27 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
 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
Aug 28 2003
parent gozem aaricia.csbnet.se writes:
In article <biknth$em5$1 digitaldaemon.com>, Ilya Minkov says...
 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

Yikes! This again (like with C) render it impossible to use the core types for fields in struct that needs to ALWAYS be of an exakt size. Best example is the TCP and IP-header struct which needs the 32bits type (and other types) to be exactly 32bits. Nothing less, nothing more. There is a need to two sorts of types IMHO. The exact ones and the "atleast" ones. The exact ones needs to be used in cases as above. The atleast ones needs to be used to make the program fast. I don't think the compiler it self can figure out when its okej to "be atleast" with only fixed types. Thus we need both sorts. /Joakim Axelsson
Aug 30 2003