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.


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
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.


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
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




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
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