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

<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

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

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

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

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

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

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