General question on the concept of integer handling in Delphi 2009

I found in system.pas new names "NativeInt" and "NativeUInt".

According to all computer languages worldwide, Integer (and Cardinal) is 
*already* a native integer that represents the CPU register for best 
performance etc...

What will happen in Delphi 2010 Win64 ??? I don't want to change Integer 
to NativeInt in my code thousand times to get adequate performance.
0
Ralf
12/24/2008 12:17:22 PM
embarcadero.delphi.non-tech 5934 articles. 1 followers. Follow

228 Replies
778 Views

Similar Articles

[PageSpeed] 4

> {quote:title=Ralf Stocker wrote:}{quote}
> I found in system.pas new names "NativeInt" and "NativeUInt".

Interesting.
 
> According to all computer languages worldwide, Integer (and Cardinal) is 
> *already* a native integer that represents the CPU register for best 
> performance etc...

Microsoft decided to use 32 bit integers in most cases in x64 because it's faster and makes porting easier. So I think integer and cardinal will remain 32 bit. I know this isn't what we've all been thinking for ten years, but I think it's true.

It would be nice if CodeGear could shed some light on this, since the issue pops up almost every week.
 
> What will happen in Delphi 2010 Win64 ??? I don't want to change Integer 
> to NativeInt in my code thousand times to get adequate performance.

It looks like you wouldn't want to use 64 bit integers to improve performance.
0
Giel
12/24/2008 12:38:34 PM
<Giel -> wrote
>
> Microsoft decided to use 32 bit integers in most cases in x64 because it's 
> faster
> and makes porting easier. So I think integer and cardinal will remain 32 
> bit.

My guess as well.

VCL-specific issue is what happens to the Tag property. I've seen lots of 
code that uses component Tag properties as a place to stash object pointers.

bobD
0
Robert
12/24/2008 2:36:33 PM
Ralf Stocker wrote:

> What will happen in Delphi 2010 Win64 ??? I don't want to change
> Integer to NativeInt in my code thousand times to get adequate
> performance.

We don't want you to, either.

-- 
Nick Hodges
Delphi Product Manager - Embarcadero
http://blogs.codegear.com/nickhodges
0
Nick
12/24/2008 4:27:35 PM
Robert Dawson wrote:

> <Giel -> wrote
> > 
> > Microsoft decided to use 32 bit integers in most cases in x64
> > because it's  faster and makes porting easier. So I think integer
> > and cardinal will remain 32  bit.
> 
> My guess as well.
> 
> VCL-specific issue is what happens to the Tag property. I've seen
> lots of code that uses component Tag properties as a place to stash
> object pointers.

I assume it could be a pointer or TObject reference instead of an
Integer.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Is your argument that the Creator of the Universe was working 
 under a deadline and His manager forced Him to rush inefficient
 designs into production?" -- John B. Breckenridge in bpot
0
Rudy
12/24/2008 6:50:57 PM
"Rudy Velthuis (TeamB)" wrote
>>
>> VCL-specific issue is what happens to the Tag property. I've seen
>> lots of code that uses component Tag properties as a place to stash
>> object pointers.
>
> I assume it could be a pointer or TObject reference instead of an
> Integer.

It's a LongInt now, but my sense is that its use actually bifurcates rather 
sharply: people assigning as tags either discrete-case values (basically, 
something that could easily be handled as an enum or ShortInt), and those 
that use it to store pointers and object references, which are going to need 
a full 64 bits.

Clearly a bit of overkill to use a 64bit value and then constantly check it 
for 0 or 1 <g>

bobD
0
Robert
12/24/2008 8:47:10 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > > 
> > > VCL-specific issue is what happens to the Tag property. I've seen
> > > lots of code that uses component Tag properties as a place to
> > > stash object pointers.
> > 
> > I assume it could be a pointer or TObject reference instead of an
> > Integer.
> 
> It's a LongInt now, but my sense is that its use actually bifurcates
> rather sharply: people assigning as tags either discrete-case values
> (basically, something that could easily be handled as an enum or
> ShortInt), and those that use it to store pointers and object
> references, which are going to need a full 64 bits.
> 
> Clearly a bit of overkill to use a 64bit value and then constantly
> check it for 0 or 1 <g>

So why not a new TagPtr property, while the old tag remains Longint?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The Six Phases of a Project:"
   o Enthusiasm
   o Disillusionment
   o Panic
   o Search for the Guilty
   o Punishment of the Innocent
   o Praise for non-participants"
0
Rudy
12/24/2008 11:08:32 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> >>
> >> VCL-specific issue is what happens to the Tag property. I've seen
> >> lots of code that uses component Tag properties as a place to stash
> >> object pointers.
> >
> > I assume it could be a pointer or TObject reference instead of an
> > Integer.
> 
> It's a LongInt now, but my sense is that its use actually bifurcates rather 
> sharply: people assigning as tags either discrete-case values (basically, 
> something that could easily be handled as an enum or ShortInt), and those 
> that use it to store pointers and object references, which are going to need 
> a full 64 bits.
> 
> Clearly a bit of overkill to use a 64bit value and then constantly check it 
> for 0 or 1 <g>

It should become a NativeInt at some point in the not too distant
future.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/25/2008 1:52:39 AM
"Ralf Stocker" <nospam@nospam.org> wrote in message 
news:59110@forums.codegear.com...
>I found in system.pas new names "NativeInt" and 
>"NativeUInt".
>
> According to all computer languages worldwide, Integer 
> (and Cardinal) is
> *already* a native integer that represents the CPU 
> register for best
> performance etc...

Sorry, but that simply is not true.  It is most efficient if 
the language defines an Integer that way, but languages 
define integers the way the language defines integers.

In the case of MS Basic (and Visual Basic through version 6) 
an Integer was two bytes.  That was true for 8 bit CPU's, 
16bit CPU's and 32bit CPU's.

One of the breaking changes MS made in the change from VB6 
to VB.Net (VB7) was to redefine the Integer.  Since no 
previous version had any other integer size than two bytes, 
and since there was no SizeOf() funciton, that change broke 
any code that was size sensitive.  Since bitwise logical 
operations were done with integers it affected a lot of 
communication and other bit sensitive routines.

If all language definitions were the same, there would be 
only one computer language.

Dan
0
Dan
12/25/2008 5:38:09 AM
Dan Barclay wrote:
> "Ralf Stocker" <nospam@nospam.org> wrote in message 
> news:59110@forums.codegear.com...
>> I found in system.pas new names "NativeInt" and 
>> "NativeUInt".
>>
>> According to all computer languages worldwide, Integer 
>> (and Cardinal) is
>> *already* a native integer that represents the CPU 
>> register for best
>> performance etc...
> 
> Sorry, but that simply is not true.  It is most efficient if 
> the language defines an Integer that way, but languages 
> define integers the way the language defines integers.
> 
> In the case of MS Basic (and Visual Basic through version 6) 
> an Integer was two bytes.  That was true for 8 bit CPU's, 
> 16bit CPU's and 32bit CPU's.
> 
> One of the breaking changes MS made in the change from VB6 
> to VB.Net (VB7) was to redefine the Integer.  Since no 
> previous version had any other integer size than two bytes, 
> and since there was no SizeOf() funciton, that change broke 
> any code that was size sensitive.  Since bitwise logical 
> operations were done with integers it affected a lot of 
> communication and other bit sensitive routines.
> 
> If all language definitions were the same, there would be 
> only one computer language.
> 
> Dan

The above statement comes from Codegear Help not from me! ;-))
0
Ralf
12/25/2008 7:55:29 AM
"Dan Barclay" wrote:
> "Ralf Stocker" wrote:
>>
>> According to all computer languages worldwide, Integer (and Cardinal) is
>> *already* a native integer that represents the CPU register for best
>> performance etc...
>
> Sorry, but that simply is not true.  It is most efficient if the language 
> defines an Integer that way, but languages define integers the way the 
> language defines integers.

Actually it is true. For example, integer operations on 32-bit CPUs a 32-bit 
integer has better performance than does a 8, 16 or 64-bit integer.

Generally it is the person designing the compiler and not the language which 
defines the size of an integer. For instance the C language uses include 
files where the size of data types are defined thus allowing for both 
performance and portability independent of the integer size used by the 
compiler in question regardless of the CPU.

> In the case of MS Basic (and Visual Basic through version 6) an Integer 
> was two bytes.  That was true for 8 bit CPU's, 16bit CPU's and 32bit 
> CPU's.

AFAIK no one claims that MS Basic (and Visual Basic through version 6) was 
optimized for maximum performance. ;-)

> One of the breaking changes MS made in the change from VB6 to VB.Net (VB7) 
> was to redefine the Integer.  Since no previous version had any other 
> integer size than two bytes, and since there was no SizeOf() funciton, 
> that change broke any code that was size sensitive.  Since bitwise logical 
> operations were done with integers it affected a lot of communication and 
> other bit sensitive routines.

It's a fact that the word "Basic" appears in both VB6 and VB.NET but they 
are two different languages. BTW no need for you to again explain your 
position vis a vis MS, I've already seen it way too many times. ;-)

> If all language definitions were the same, there would be only one 
> computer language.

That dawg ain't gonna hunt!!
0
John
12/25/2008 7:59:28 AM
Ralf Stocker wrote:
> Dan Barclay wrote:
>> "Ralf Stocker" <nospam@nospam.org> wrote in message 
>> news:59110@forums.codegear.com...
>>> I found in system.pas new names "NativeInt" and 
>>> "NativeUInt".
>>>
>>> According to all computer languages worldwide, Integer 
>>> (and Cardinal) is
>>> *already* a native integer that represents the CPU 
>>> register for best
>>> performance etc...
>> Sorry, but that simply is not true.  It is most efficient if 
>> the language defines an Integer that way, but languages 
>> define integers the way the language defines integers.
>>
>> In the case of MS Basic (and Visual Basic through version 6) 
>> an Integer was two bytes.  That was true for 8 bit CPU's, 
>> 16bit CPU's and 32bit CPU's.
>>
>> One of the breaking changes MS made in the change from VB6 
>> to VB.Net (VB7) was to redefine the Integer.  Since no 
>> previous version had any other integer size than two bytes, 
>> and since there was no SizeOf() funciton, that change broke 
>> any code that was size sensitive.  Since bitwise logical 
>> operations were done with integers it affected a lot of 
>> communication and other bit sensitive routines.
>>
>> If all language definitions were the same, there would be 
>> only one computer language.
>>
>> Dan
> 
> The above statement comes from Codegear Help not from me! ;-))

-->

*Generic* integer types
*Fundamental* Integer Types
0
Ralf
12/25/2008 8:04:59 AM
"John Cash"
> Actually it is true. For example, integer operations on 32-bit CPUs a 
> 32-bit
> integer has better performance than does a 8, 16 or 64-bit integer.

Also, aligning data storage locations to 2/4/8-bytes is very important for 
best performance. On a 32-bit CPU accessing an aligned 32-bit integer is 
much faster than a non-aligned one.
0
farshad
12/25/2008 9:35:10 AM
"Barry Kelly" wrote
>
> It [= the TComponent.Tag property] should become a NativeInt at some point 
> in the not too distant
> future.

That's going to break any current code that uses Tag to store pointers, no?

bobD
0
Robert
12/25/2008 4:54:29 PM
Back to the question. According to the rule from Help (see below), 
Integer and Cardinal would become 64 bit in Delphi 2010.
The software emulated Int64 would become a "real" register variable 
type. Maybe there would be a new pseudo Int128/UInt128.
NativeInt would break this rules and causes a lot of work in the 
RTL/VCL/customer sources.

 From the Help:

An integer type represents a subset of the whole numbers.
The generic integer types are Integer and Cardinal;
use these whenever possible, since they result in the best
performance for the underlying CPU and operating system.
The table below gives their ranges and storage formats
for the current 32-bit Object Pascal compiler.

*Generic* integer types

Type	Range	Format
Integer	–2147483648..2147483647	signed 32-bit
Cardinal	0..4294967295	unsigned 32-bit


*Fundamental* integer types include Shortint, Smallint, Longint, Int64, 
Byte, Word, and Longword.

Type	Range	Format
Shortint	–128..127	signed 8-bit
Smallint	–32768..32767	signed 16-bit
Longint	–2147483648..2147483647	signed 32-bit
Byte	0..255	unsigned 8-bit
Word	0..65535	unsigned 16-bit
Longword	0..4294967295	unsigned 32-bit
Int64	–2^63..2^63–1	signed 64-bit
0
Ralf
12/25/2008 5:39:25 PM
*Generic* integer types

Type	        Range	        Format
Integer	        –263..263–1	signed 64-bit
Cardinal	0..264-1        unsigned 64-bit


*Fundamental* integer types

Type	        Range	        Format
Shortint	–128..127	signed 8-bit
Smallint	–32768..32767	signed 16-bit
Longint		–2147483648..2147483647	signed 32-bit
Byte		0..255		unsigned 8-bit
Word		0..65535	unsigned 16-bit
Longword	0..4294967295	unsigned 32-bit
Int8   				= ShortInt
Int16  				= SmallInt
Int32  				= Longint
Int64		–263..263–1	signed 64-bit
Int128				signed 128-bit
UInt8  				= Byte
UInt16 				= Word
UInt32 				= Longword
UInt64 				unsigned 64-bit
UInt128				unsigned 128-bit
0
Ralf
12/25/2008 5:52:11 PM
Farshad Mohajeri wrote:

> "John Cash"
> > Actually it is true. For example, integer operations on 32-bit CPUs
> > a  32-bit integer has better performance than does a 8, 16 or
> > 64-bit integer.
> 
> Also, aligning data storage locations to 2/4/8-bytes is very
> important for best performance. On a 32-bit CPU accessing an aligned
> 32-bit integer is much faster than a non-aligned one.

And some newer 64 bit CPUs are even more sensitive to alignment, i.e.
some might even cause an exception if data is not aligned.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"There is a charm about the forbidden that makes it unspeakably
 diserable." -- Mark Twain.
0
Rudy
12/25/2008 6:08:17 PM
"Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message 
news:59380@forums.codegear.com...
> Farshad Mohajeri wrote:
>
>> "John Cash"
>> > Actually it is true. For example, integer operations on 32-bit CPUs
>> > a  32-bit integer has better performance than does a 8, 16 or
>> > 64-bit integer.
>>
>> Also, aligning data storage locations to 2/4/8-bytes is very
>> important for best performance. On a 32-bit CPU accessing an aligned
>> 32-bit integer is much faster than a non-aligned one.
>
> And some newer 64 bit CPUs are even more sensitive to alignment, i.e.
> some might even cause an exception if data is not aligned.
>

Yes, ARM series requires all data to be aligned on 32-bit boundry otherwise 
it wont run your code and raises an exception.
0
farshad
12/25/2008 6:15:42 PM
Farshad Mohajeri wrote:

> > > Also, aligning data storage locations to 2/4/8-bytes is very
> > > important for best performance. On a 32-bit CPU accessing an
> > > aligned 32-bit integer is much faster than a non-aligned one.
> > 
> > And some newer 64 bit CPUs are even more sensitive to alignment,
> > i.e.  some might even cause an exception if data is not aligned.
> > 
> 
> Yes, ARM series requires all data to be aligned on 32-bit boundry
> otherwise it wont run your code and raises an exception.

AHA! One of the reasons why I am so against the abuse of "packed" in
many API conversions, when packed was never specified in the original
sources. Using "packed" has some other disadvantages as well.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Before software can be reusable it first has to be usable."
 -- Ralph Johnson
0
Rudy
12/25/2008 6:19:19 PM
"Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message 
news:59383@forums.codegear.com...
> Farshad Mohajeri wrote:
>
>> > > Also, aligning data storage locations to 2/4/8-bytes is very
>> > > important for best performance. On a 32-bit CPU accessing an
>> > > aligned 32-bit integer is much faster than a non-aligned one.
>> >
>> > And some newer 64 bit CPUs are even more sensitive to alignment,
>> > i.e.  some might even cause an exception if data is not aligned.
>> >
>>
>> Yes, ARM series requires all data to be aligned on 32-bit boundry
>> otherwise it wont run your code and raises an exception.
>
> AHA! One of the reasons why I am so against the abuse of "packed" in
> many API conversions, when packed was never specified in the original
> sources. Using "packed" has some other disadvantages as well.
>
> -- 

Interestingly, "Packed Records" was one of the problems which FPC guys had 
to deal with when developing the ARM compiler for Free Pascal.
0
farshad
12/25/2008 6:53:19 PM
> {quote:title=Robert Dawson wrote:}{quote}
> That's going to break any current code that uses Tag to store pointers, no?

No, because sizeof(pointer) = sizeof(NativeInt). That's why NativeInt is introduced.
0
Giel
12/25/2008 7:42:14 PM
> {quote:title=Ralf Stocker wrote:}{quote}
> According to the rule from Help (see below), 
> Integer and Cardinal would become 64 bit in Delphi 2010.

This help text was written about 12 years ago, when all they cared about was 16 and 32 bit. I wouldn't draw any conclusions from that.
0
Giel
12/25/2008 7:45:16 PM
<Giel -> wrote in message news:59401@forums.codegear.com...
>
> No, because sizeof(pointer) = sizeof(NativeInt). That's why NativeInt is 
> introduced.

that was the question, really--what's the definition of NativeInt?

Sounds like you're saying that NativeInt becomes what 'Integer' started out 
to be: a generic integer type aligned to the the hardware.

The notion of "tied to the hardware" is still a bit vague of course. What 
would NativeInt be on an i386sx (32bit registers, 16bit external data bus, 
24bit memory address space)?

bobD
0
Robert
12/25/2008 8:15:07 PM
> {quote:title=Robert Dawson wrote:}{quote}
> <Giel -> wrote in message news:59401@forums.codegear.com...
> Sounds like you're saying that NativeInt becomes what 'Integer' started out 
> to be

Well, that's what I read in Barry's cryptic message :-)
0
Giel
12/25/2008 8:28:19 PM
Robert Dawson wrote:

> "Barry Kelly" wrote
> >
> > It [= the TComponent.Tag property] should become a NativeInt at some point 
> > in the not too distant
> > future.
> 
> That's going to break any current code that uses Tag to store pointers, no?

No, SizeOf(NativeInt) == SizeOf(Pointer).

The size of Integer and Longint are related to the ABI of the underlying
platform, specifically 'int' and 'long' in C. On Windows on x64, both
int and long are 4 bytes, so so will Integer and Longint in Delphi on
x64.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/25/2008 8:35:49 PM
Thanks for sharing this :-)
0
Giel
12/25/2008 10:04:43 PM
Robert,

| The notion of "tied to the hardware" is still a bit vague of course.
| What would NativeInt be on an i386sx (32bit registers, 16bit external
| data bus, 24bit memory address space)?

I had the same mental questions!

-- 

   Q

12/25/2008 14:30:32

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/25/2008 10:31:45 PM
"Barry Kelly" wrote
>
> The size of Integer and Longint are related to the ABI of the underlying
> platform, specifically 'int' and 'long' in C. On Windows on x64, both
> int and long are 4 bytes, so so will Integer and Longint in Delphi on
> x64.

So to go back to the long-standing help file guidance that Ralf Stocker 
already quoted, Integer is becoming a 'fundamental' type (ie, fixed size 
regardless of platform), and NativeInt is replacing Integer as the 'generic' 
inteeger type.

I presume that Cardinal will also be frozen at 32bits? Will a new unsigned 
NativeInt be introduced?

bobD
0
Robert
12/25/2008 11:07:05 PM
> {quote:title=Robert Dawson wrote:}{quote}
> So to go back to the long-standing help file guidance that Ralf Stocker 
> already quoted, Integer is becoming a 'fundamental' type (ie, fixed size 
> regardless of platform),

No, Integer just happens to be 32 bit on x64 as well. It's the generic type for an "I don't care what size it is, do what you think is best" integer. It can have a different size on future platforms.


> I presume that Cardinal will also be frozen at 32bits? Will a new unsigned 
> NativeInt be introduced?

NativeUInt seems to be in system.pas, so one can assume that's it.
0
Giel
12/25/2008 11:36:51 PM
Robert Dawson wrote:

> "Barry Kelly" wrote
> > 
> > The size of Integer and Longint are related to the ABI of the
> > underlying platform, specifically 'int' and 'long' in C. On Windows
> > on x64, both int and long are 4 bytes, so so will Integer and
> > Longint in Delphi on x64.
> 
> So to go back to the long-standing help file guidance that Ralf
> Stocker already quoted, Integer is becoming a 'fundamental' type (ie,
> fixed size regardless of platform)

It is still a generic type, it is just not the same size as the CPU
registers anymore. That it remains 32 bit is because the platform
(Win64) also uses 32 bit integers. It would simply be overkill to make
all integers 64 bit.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The Six Phases of a Project:"
   o Enthusiasm
   o Disillusionment
   o Panic
   o Search for the Guilty
   o Punishment of the Innocent
   o Praise for non-participants"
0
Rudy
12/25/2008 11:46:38 PM
Quentin Correll wrote:

> Robert,
> 
> >  The notion of "tied to the hardware" is still a bit vague of
> > course.   What would NativeInt be on an i386sx (32bit registers,
> > 16bit external  data bus, 24bit memory address space)?
> 
> I had the same mental questions!

A native INTEGER should of course be the size of the accumulator, i.e.
32bit on an i386sx.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

Bible, Dijkstra 5:15
"and the clueless shall spend their time reinventing the wheel 
 while the elite merely use the Wordstar key mappings" 
 -- Ed Mulroy
0
Rudy
12/25/2008 11:53:42 PM
Rudy,

| A native INTEGER should of course be the size of the accumulator, i.e.
| 32bit on an i386sx.

That's also what I think.

-- 

   Q

12/25/2008 16:33:39

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/26/2008 12:35:15 AM
"Rudy Velthuis (TeamB)" wrote
>
> It is still a generic type, it is just not the same size as the CPU
> registers anymore.

A distinction without a difference: if Integer isn't changing with register 
size to 64bit, then its status as 'generic' is rather meaningless.

Unless you thnk we'll be seeing 128bit in the foreseeable future ...<g>

> That it remains 32 bit is because the platform
> (Win64) also uses 32 bit integers.

Or you think MS will make Integer 64bit in some future 64bit version of 
Windows.

bobD
0
Robert
12/26/2008 1:20:55 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > It is still a generic type, it is just not the same size as the CPU
> > registers anymore.
> 
> A distinction without a difference: if Integer isn't changing with
> register size to 64bit, then its status as 'generic' is rather
> meaningless.

Depends on what you consider "generic". Since 32 bit will also be the
size of the OS integers, I think 32 bit are generic alright, even using
the definition in the Delphi help.

IOW, there is nothing in the definition of "generic" that says it
should be register size.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Men are not disturbed by things, but the view they take of 
 things." -- Epictetus (55-135 A.D.)

"What about things like bullets?"
 -- Herb Kimmel, Behavioralist, Professor of Psychology, upon 
    hearing the above quote (1981)
0
Rudy
12/26/2008 1:41:44 AM
Robert Dawson wrote:
> "Rudy Velthuis (TeamB)" wrote
>> It is still a generic type, it is just not the same size as the CPU
>> registers anymore.
> 
> A distinction without a difference: if Integer isn't changing with register 
> size to 64bit, then its status as 'generic' is rather meaningless.

100% ack.

#1
What is the benefit when all integers in the VCL/RTL etc remain on 
"Integer" (=32 bit) on Win64 platform???

#2
I guess, some controls in the VCL need 64 bit integers to work proper on 
Win64 platform. A lot of source needs to be changed if NativeInt is 64 
bit and Integer remains 32 bit.

#3
According to Codegear, RTL/VCL is common source on Win32 and Win64 in 
Delphi 2010. What happens here?
0
Ralf
12/26/2008 1:46:45 AM
Rudy Velthuis (TeamB) wrote:
> Robert Dawson wrote:
> 
>> "Rudy Velthuis (TeamB)" wrote
>>> It is still a generic type, it is just not the same size as the CPU
>>> registers anymore.
>> A distinction without a difference: if Integer isn't changing with
>> register size to 64bit, then its status as 'generic' is rather
>> meaningless.
> 
> Depends on what you consider "generic". Since 32 bit will also be the
> size of the OS integers, I think 32 bit are generic alright, even using
> the definition in the Delphi help.
> 
> IOW, there is nothing in the definition of "generic" that says it
> should be register size.

I would say, a type is Generic when its size matches the cpu register 
(best performance, no masking etc). This is OS independent.

Okay, at the moment, we have the stupid situation that the majority is 
running Win32 on 64 bit CPUs.
0
Ralf
12/26/2008 1:52:25 AM
Robert Dawson wrote:

> Integer is becoming a 'fundamental' type (ie, fixed size 
> regardless of platform),

No. Integer is 16-bit on 16-bit platforms. It's 32-bit on Win32 and
Win64.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/26/2008 2:20:30 AM
Ralf Stocker wrote:

> What is the benefit when all integers in the VCL/RTL etc remain on 
> "Integer" (=32 bit) on Win64 platform???

I'm not quite getting your point here. What benefit to what, under what
circumstances? And how have you measured it?

FWIW, the decision to use 32-bit integers on Win64 was Microsoft's, not
ours. I also think it's the right decision.

> I guess, some controls in the VCL need 64 bit integers to work proper on 
> Win64 platform.

Very little code, in the scheme of things, needs 64-bit integers. The
few that do, like file / stream APIs, often require 64-bit even on
32-bit OSes.

> A lot of source needs to be changed if NativeInt is 64 
> bit and Integer remains 32 bit.

What source exactly? Code that assumes that SizeOf(Pointer) =
SizeOf(Integer), yes. But there ought not to be a huge amount of that -
it is a type violation, after all. Such Integer uses should be replaced
by NativeInt. We'll likely add a warning for such typecasts in short
order.

> According to Codegear, RTL/VCL is common source on Win32 and Win64 in 
> Delphi 2010. What happens here?

Integers that need to float with the pointer size (such as ones
represented with INTPTR or equivalent (HANDLE etc.) in the WinAPI)
should change to NativeInt, NativeUInt or aliases thereof. Integers that
don't, won't.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/26/2008 2:30:31 AM
Ralf Stocker wrote:

> > IOW, there is nothing in the definition of "generic" that says it
> > should be register size.
> 
> I would say, a type is Generic when its size matches the cpu register 
> (best performance, no masking etc). 

I wouldn't, and I already explained why. Like someone said, a "generic"
type is a type used in the "I don't care about the exact size"
situation, since the size can be chosen to be the best for the platform
and/or CPU situation. It would be plain silly to use 64 bit when the OS
still uses 32 bit.

It is not a fixed size - fundamental -  type, like Byte, Shortint
(always 1 byte), Word, Smallint (always 2 bytes), Longword, Longint
(always 4 bytes) and UIt64, Int64 (always 8 bytes).
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Should array indices start at 0 or 1? My compromise of 0.5 was
 rejected without, I thought, proper consideration."
 -- Stan Kelly-Bootle
0
Rudy
12/26/2008 2:34:07 AM
Barry Kelly wrote:

> Ralf Stocker wrote:
> 
> > What is the benefit when all integers in the VCL/RTL etc remain on 
> > "Integer" (=32 bit) on Win64 platform???
> 
> I'm not quite getting your point here. What benefit to what, under
> what circumstances? And how have you measured it?
> 
> FWIW, the decision to use 32-bit integers on Win64 was Microsoft's,
> not ours. I also think it's the right decision.

Indeed, since I assume that in most cases, the top 32 bit would be
completely wasted (not used) anyway. Just think of the situations where
integers are used. Not many of them would benefit from an extra 32
bits, so the extra 32 bits would generally be a waste of memory,
especially if ALL integers were 64 bit.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Plan to throw one away, you will anyhow." -- Fred Brooks
0
Rudy
12/26/2008 2:36:57 AM
Barry Kelly wrote:
> Robert Dawson wrote:
> 
>> Integer is becoming a 'fundamental' type (ie, fixed size 
>> regardless of platform),
> 
> No. Integer is 16-bit on 16-bit platforms. It's 32-bit on Win32 and
> Win64.
> 
> -- Barry
> 

And integer is a 16-bit value on 8-bit platforms...

David Erbas-White
0
David
12/26/2008 3:32:02 AM
"Barry Kelly" wrote
>
> No. Integer is 16-bit on 16-bit platforms.

Is that relevant when the question was whether the definition has changed?

bobD
0
Robert
12/26/2008 3:34:00 AM
"Barry Kelly" wrote

> FWIW, the decision to use 32-bit integers on Win64 was Microsoft's, not
> ours. I also think it's the right decision.

In my own case at least, what's right or wrong is not at issue. I'm just 
trying to come to some conceptual clarity about what the terms mean. Would 
the following be correct?

LongInt: fundamental type fixed at 32bits
Integer: generic type, size determined by standard 'Integer' definition of 
OS
NativeInt: generic type, size determined by data width of hardware logical 
memory address space--essentially sizeof(pointer)

bobD
0
Robert
12/26/2008 3:43:16 AM
"Rudy Velthuis (TeamB)" <
>> FWIW, the decision to use 32-bit integers on Win64 was Microsoft's,
>> not ours. I also think it's the right decision.
>
> Indeed, since I assume that in most cases, the top 32 bit would be
> completely wasted (not used) anyway. Just think of the situations where
> integers are used. Not many of them would benefit from an extra 32
> bits, so the extra 32 bits would generally be a waste of memory,
> especially if ALL integers were 64 bit.
> -- 

Exactly, 64-Bit integers would have no real use at all. 32-Bit integers are 
enough for 99% of tasks and if you need a wider integer you can declare it 
explicitly using Int64 type.
0
farshad
12/26/2008 9:03:46 AM
> {quote:title=Ralf Stocker wrote:}{quote}
> #1
> What is the benefit when all integers in the VCL/RTL etc remain on 
> "Integer" (=32 bit) on Win64 platform???
> 
> #2
> I guess, some controls in the VCL need 64 bit integers to work proper on 
> Win64 platform. A lot of source needs to be changed if NativeInt is 64 
> bit and Integer remains 32 bit.
> 
> #3
> According to Codegear, RTL/VCL is common source on Win32 and Win64 in 
> Delphi 2010. What happens here?

Note that Microsoft also uses 32 bit integers just about everywhere in their 64 bit code, not 64 bit. I was equally shocked when I found out about that a couple of years ago. But there really isn't a problem, your code will work fine, except for integer <--> pointer casts, you'll have to use NativeInt/NativeUInt for that.
0
Giel
12/26/2008 9:20:02 AM
Robert Dawson wrote:

> LongInt: fundamental type fixed at 32bits

Exactly.

> Integer: generic type, size determined by standard 'Integer'
> definition of OS 

Size determined by compiler writers, but based on default integer sizes
of the OS or platform.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"People demand freedom of speech to make up for the freedom of 
 thought which they avoid."
 -- Soren Aabye Kierkegaard (1813-1855)
0
Rudy
12/26/2008 12:55:10 PM
David Erbas-White wrote:

> Barry Kelly wrote:
> > Robert Dawson wrote:
> > 
> >> Integer is becoming a 'fundamental' type (ie, fixed size 
> >> regardless of platform),
> > 
> > No. Integer is 16-bit on 16-bit platforms. It's 32-bit on Win32 and
> > Win64.
> > 
> > -- Barry
> > 
> 
> And integer is a 16-bit value on 8-bit platforms...

Indeed.



-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Many journalists have fallen for the conspiracy theory of 
 government. I do assure you that they would produce more 
 accurate work if they adhered to the cock-up theory." 
 -- Sir Bernard Ingham
0
Rudy
12/26/2008 12:55:48 PM
Codegear will follow Microsoft. Is doing the same mistakes as Microsoft. 
Using 32 bit integers on a 64 bit platform is generating a lot of extra 
code. It is not faster, it is slower than using native 64 bit integer. 
There would be a lot of masking out/handling/merging the higher 32 bits.
I think nobody would use Int16 on nowadays 32 bit OS'es for general tasks.


Barry Kelly wrote:
> Ralf Stocker wrote:
> 
>> What is the benefit when all integers in the VCL/RTL etc remain on 
>> "Integer" (=32 bit) on Win64 platform???
> 
> I'm not quite getting your point here. What benefit to what, under what
> circumstances? And how have you measured it?
> 
> FWIW, the decision to use 32-bit integers on Win64 was Microsoft's, not
> ours. I also think it's the right decision.
> 
>> I guess, some controls in the VCL need 64 bit integers to work proper on 
>> Win64 platform.
> 
> Very little code, in the scheme of things, needs 64-bit integers. The
> few that do, like file / stream APIs, often require 64-bit even on
> 32-bit OSes.
> 
>> A lot of source needs to be changed if NativeInt is 64 
>> bit and Integer remains 32 bit.
> 
> What source exactly? Code that assumes that SizeOf(Pointer) =
> SizeOf(Integer), yes. But there ought not to be a huge amount of that -
> it is a type violation, after all. Such Integer uses should be replaced
> by NativeInt. We'll likely add a warning for such typecasts in short
> order.
> 
>> According to Codegear, RTL/VCL is common source on Win32 and Win64 in 
>> Delphi 2010. What happens here?
> 
> Integers that need to float with the pointer size (such as ones
> represented with INTPTR or equivalent (HANDLE etc.) in the WinAPI)
> should change to NativeInt, NativeUInt or aliases thereof. Integers that
> don't, won't.
> 
> -- Barry
>
0
Ralf
12/26/2008 1:25:18 PM
Ralf Stocker wrote:

> Codegear will follow Microsoft. Is doing the same mistakes as
> Microsoft.  Using 32 bit integers on a 64 bit platform is generating
> a lot of extra code. It is not faster, it is slower than using native
> 64 bit integer.

Is it, actually? Is 32 bit access on an x86-64 slower than 64 bit
access? What extra code do you mean?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Java: the elegant simplicity of C++ and the blazing speed of
 Smalltalk." -- Roland Turner
0
Rudy
12/26/2008 4:08:51 PM
> {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> 
> Size determined by compiler writers,

Unless one can say _how_ they determine it, this answer reduces to 'Integer is an essentially unpredictable type, and no one in his right mind should use it."

> but based on default integer sizes
> of the OS or platform.

'platform' is unusably vague, and you propose an 'OR' option without a discriminator, so even with this qualification you're still proposing an explanation that makes Integer size effectively unpredictable.

bobD
0
Robert
12/26/2008 8:40:18 PM
Ralf Stocker wrote:

> Back to the question. According to the rule from Help (see below), 
> Integer and Cardinal would become 64 bit in Delphi 2010.

See below.


> NativeInt would break this rules and causes a lot of work in the 
> RTL/VCL/customer sources.

Just for the record and although not widely promoted NativeInt is/was
already available in D7.


> From the Help:
> 
> An integer type represents a subset of the whole numbers.
> The generic integer types are Integer and Cardinal;
> use these whenever possible, since they result in the best
> performance for the underlying CPU and operating system.

How do you translate this so that it has to be 64 bit?
Moreover Microsoft (those who write the OS) already decided that
Integer will stay 32 bit.

-- 
Pieter

"Wise men make proverbs, but fools repeat them."
    - Samuel Palmer (1805-80)
0
Pieter
12/27/2008 12:30:21 AM
Robert Dawson wrote:

> > {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> > 
> > Size determined by compiler writers,
> 
> Unless one can say how they determine it, this answer reduces to
> "Integer is an essentially unpredictable type, 

Nothing changed here in the last > 12 years of Delphi and other program
languages.

> and no one in his right mind should use it."

Not when size matters ;-)

OTOH you can/should use it as a generic type which normally performs
best on the underlying CPU *and* OS.

-- 
Pieter

"A low voter turnout is an indication of fewer people going to 
 the polls." -- George W. Bush
0
Pieter
12/27/2008 12:37:55 AM
Rudy Velthuis (TeamB) wrote:
> Ralf Stocker wrote:
> 
>> Codegear will follow Microsoft. Is doing the same mistakes as
>> Microsoft.  Using 32 bit integers on a 64 bit platform is generating
>> a lot of extra code. It is not faster, it is slower than using native
>> 64 bit integer.
> 
> Is it, actually? Is 32 bit access on an x86-64 slower than 64 bit
> access? What extra code do you mean?
> 

As far as I know the following is still true:
http://developer.amd.com/documentation/articles/pages/7162004127.aspx

#11. Use 32-bit integers instead of 8-bit or 16-bit integers

This is a tip specifically for 32-bit applications running either
natively on a 32-bit operating system, or within a 64-bit operating
system. You'll see better performance because operations on 8-bit or
16-bit integers are often less efficient. Of course, you'll be using
twice or four times the memory, so be aware of that trade-off.

By the way, 32-bit integers execute at full speed when you're running in
64-bit mode, so unless you need the extra bits for some
application-specific reason, you should stick to 32-bit ones.

Brian Evans
0
Brian
12/27/2008 1:59:07 AM
"John Cash" <JohnJ@nada.com> wrote in message 
news:59322@forums.codegear.com...
> "Dan Barclay" wrote:
>> "Ralf Stocker" wrote:
>>>
>>> According to all computer languages worldwide, Integer 
>>> (and Cardinal) is
>>> *already* a native integer that represents the CPU 
>>> register for best
>>> performance etc...
>>
>> Sorry, but that simply is not true.  It is most efficient 
>> if the language
>> defines an Integer that way, but languages define 
>> integers the way the
>> language defines integers.
>
> Actually it is true. For example, integer operations on 
> 32-bit CPUs a 32-bit
> integer has better performance than does a 8, 16 or 64-bit 
> integer.

No, the statement "According to all computer languages 
worldwide, Integer ( and Cardinal) is *already* a native 
integer that represents the CPU register..." is not true. 
Again *all* computer languages do not define their Integer 
as native size.  These languages may lose performance by not 
using the native size, but the definition can be (and 
sometimes is) other than native size.

I don't know what's so confusing about that.  In fact, I 
gave a very specific example.

> Generally it is the person designing the compiler and not 
> the language which
> defines the size of an integer. For instance the C 
> language uses include
> files where the size of data types are defined thus 
> allowing for both
> performance and portability independent of the integer 
> size used by the
> compiler in question regardless of the CPU.

The C language *defines* the integer as being a variable 
size.  Actually it does specify a minimum size, but the 
upper size can reflect the CPU and still be within the 
language definition.

>
>> In the case of MS Basic (and Visual Basic through version 
>> 6) an Integer
>> was two bytes.  That was true for 8 bit CPU's, 16bit 
>> CPU's and 32bit
>> CPU's.
>
> AFAIK no one claims that MS Basic (and Visual Basic 
> through version 6) was
> optimized for maximum performance. ;-)

The statement above did not say anything about performance. 
Look again.  It said "According to all computer 
languages..."

Not that it applies to this discussion, but the later DOS 
optimizing compilers were very good.   In fact, they used 
full register operations even if truncating for language 
definition reasons.  Language definition and optimization 
are two different issues, though some languages allow you to 
take advantage of changes within the definition to help 
performance.

>> One of the breaking changes MS made in the change from 
>> VB6 to VB.Net (VB7)
>> was to redefine the Integer.  Since no previous version 
>> had any other
>> integer size than two bytes, and since there was no 
>> SizeOf() funciton,
>> that change broke any code that was size sensitive. 
>> Since bitwise logical
>> operations were done with integers it affected a lot of 
>> communication and
>> other bit sensitive routines.
>
> It's a fact that the word "Basic" appears in both VB6 and 
> VB.NET but they
> are two different languages. BTW no need for you to again 
> explain your
> position vis a vis MS, I've already seen it way too many 
> times. ;-)

It's simply an example.  In languages (like C and Delphi) 
that allow for changing size of types it is not an issue.

>
>> If all language definitions were the same, there would be 
>> only one
>> computer language.
>
> That dawg ain't gonna hunt!!

Oh, this should be interesting.  Do you claim that all 
language definitions are the same?  If not, please explain 
what part of the statement you disagree with.

Dan
0
Dan
12/27/2008 4:39:53 AM
"Farshad Mohajeri" <farshad@ATfmsoft.DOTnet> wrote in 
message news:59389@forums.codegear.com...
> "Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in 
> message news:59383@forums.codegear.com...
>> Farshad Mohajeri wrote:
>>
>>> > > Also, aligning data storage locations to 2/4/8-bytes 
>>> > > is very
>>> > > important for best performance. On a 32-bit CPU 
>>> > > accessing an
>>> > > aligned 32-bit integer is much faster than a 
>>> > > non-aligned one.
>>> >
>>> > And some newer 64 bit CPUs are even more sensitive to 
>>> > alignment,
>>> > i.e.  some might even cause an exception if data is 
>>> > not aligned.
>>> >
>>>
>>> Yes, ARM series requires all data to be aligned on 
>>> 32-bit boundry
>>> otherwise it wont run your code and raises an exception.
>>
>> AHA! One of the reasons why I am so against the abuse of 
>> "packed" in
>> many API conversions, when packed was never specified in 
>> the original
>> sources. Using "packed" has some other disadvantages as 
>> well.
>>
>> -- 
>
> Interestingly, "Packed Records" was one of the problems 
> which FPC guys had to deal with when developing the ARM 
> compiler for Free Pascal.

Packed is certainly handy for building communication 
buffers.  Before using Delphi we had manually build the 
buffers, a real PITA.

Dan
0
Dan
12/27/2008 4:43:08 AM
> {quote:title=Pieter Zijlstra wrote:}{quote}
> Just for the record and although not widely promoted NativeInt is/was
> already available in D7.

It's not in my D2007....
0
Giel
12/27/2008 9:07:19 AM
"Dan Barclay" wrote:
> "John Cash" wrote:
>
> The C language *defines* the integer as being a variable size.  Actually 
> it does specify a minimum size, but the upper size can reflect the CPU and 
> still be within the language definition.

Well, not exactly... ;-)

Actually std C (K&R p34) *defines* the basic data type "int an integer, 
typically the natural size of an integer on the host machine."

"In addition there are a number of qualifiers which can be applied to int's: 
short, long and unsigned: short and long refer to the different sizes of 
integers."

"...each compiler is free to interprert short and long as appropriate for 
it's own hardware. About all you should count on is that short is no longer 
than long."

>>> If all language definitions were the same, there would be only one
>>> computer language.
>>
>> That dawg ain't gonna hunt!!
>
> Oh, this should be interesting.  Do you claim that all language 
> definitions are the same?  If not, please explain what part of the 
> statement you disagree with.

If all definitions were the same in all languages would it be named 
Esperanto... ;-)
0
John
12/27/2008 9:19:46 AM
Giel - wrote:

> > {quote:title=Pieter Zijlstra wrote:}{quote}
> > Just for the record and although not widely promoted NativeInt
> > is/was already available in D7.
> 
> It's not in my D2007....

Try this in D7 or D2007.

type
  TForm1 = class(TForm)
    Timer1: TTimer;
    procedure Timer1Timer(Sender: TObject);
  private
    FNativeInt: NativeInt;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Caption := IntToStr(FNativeInt);
  Inc(FNativeInt);
end;

end.


-- 
Pieter

"The first half of our life is ruined by our parents and the 
 second half by our children." -- Clarence Darrow.
0
Pieter
12/27/2008 9:23:32 AM
> {quote:title=Pieter Zijlstra wrote:}{quote}
> Giel - wrote:
> 
> > > {quote:title=Pieter Zijlstra wrote:}{quote}
> > > Just for the record and although not widely promoted NativeInt
> > > is/was already available in D7.
> > 
> > It's not in my D2007....
> 
> Try this in D7 or D2007.
> 
> type
>   TForm1 = class(TForm)
>     Timer1: TTimer;
>     procedure Timer1Timer(Sender: TObject);
>   private
>     FNativeInt: NativeInt;
>   end;

Oh, that works indeed. But sizeof(system.NativeInt) = 8 !?!
That's why my code wouldn't compile after removing my "type NativeInt = integer" declaration.
0
Giel
12/27/2008 9:36:11 AM
Robert Dawson wrote:

> > {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> > 
> > Size determined by compiler writers,
> 
> Unless one can say how they determine it

They choose the size that makes most sense and then document it.
Generic means that the exact size should not really matter. If size
matters (heheh), then you should use one of the fundamental types.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"UNIX is simple. It just takes a genius to understand its
 simplicity." -- Dennis Ritchie
0
Rudy
12/27/2008 10:41:17 AM
Pieter Zijlstra wrote:

> > and no one in his right mind should use it."
> 
> Not when size matters ;-)
> 
> OTOH you can/should use it as a generic type which normally performs
> best on the underlying CPU and OS.

Exactly. One should trust the compiler writers so much that they won't
choose, say, Shortint to be the default integer type.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The President has kept all of the promises he intended to keep."
 -- Clinton aide George Stephanopolous speaking on Larry 
    King Live
0
Rudy
12/27/2008 10:43:05 AM
Brian Evans wrote:

> By the way, 32-bit integers execute at full speed when you're running
> in 64-bit mode, so unless you need the extra bits for some
> application-specific reason, you should stick to 32-bit ones.

Thanks, that is what I expected. So using 32 bit instead of 64 bit has
no obvious disadvantages, but saves us quite a lot of memory. For most
uses, 32 bits are already overkill, but they make sense
performance-wise. Using 64 bits by default would be ridiculous.

I guess for some, using 32 bits when you CAN have 64 bits with the same
performance is like choosing the smaller BMW when you could have the
one with the bigger engine for the same price. <g>
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"It is better to be quotable than to be honest." -- Tom Stoppard
0
Rudy
12/27/2008 10:49:57 AM
Giel - wrote:

> > {quote:title=Pieter Zijlstra wrote:}{quote}
> > Giel - wrote:
> > 
> > > > {quote:title=Pieter Zijlstra wrote:}{quote}
> > > > Just for the record and although not widely promoted NativeInt
> > > > is/was already available in D7.
> > > 
> > > It's not in my D2007....
> > 
> > Try this in D7 or D2007.
> > 
> > type
> >   TForm1 = class(TForm)
> >     Timer1: TTimer;
> >     procedure Timer1Timer(Sender: TObject);
> >   private
> >     FNativeInt: NativeInt;
> >   end;
> 
> Oh, that works indeed. But sizeof(system.NativeInt) = 8 !?!
> That's why my code wouldn't compile after removing my "type NativeInt
> = integer" declaration.

Indeed it is broken in D2007...

<q>
Subject: Re: D2008 with D2007?
Date: 22 Jul 2008 16:13:54 -0700
Message-ID: <488669b2$1@newsgroups.borland.com>
Newsgroups: borland.public.delphi.non-technical

Yep. Delphi/64 will follow the LLP64 data model due to the need to
match the underlying platform. We already have some types that will
follow the "natural" data size of the CPU. NativeInt and NativeUInt.
However in D2007, they're actually broken in that SizeOf(NativeInt) =
SizeOf(Int64) :-(. We fixed this for Tiburon, SizeOf(NativeInt) =
SizeOf(Integer)

-- 
Allen Bauer
CodeGear/Embarcadero
Chief Scientist
http://blogs.codegear.com/abauer
</q>

-- 
Pieter

"When you hear hoofbeats, think of horses, not zebras."
-- Old saying
0
Pieter
12/27/2008 10:50:47 AM
Dan Barclay wrote:

> > Interestingly, "Packed Records" was one of the problems  which FPC
> > guys had to deal with when developing the ARM  compiler for Free
> > Pascal.
> 
> Packed is certainly handy for building communication buffers.  Before
> using Delphi we had manually build the buffers, a real PITA.

Sure, but you can have the same effect when you stream the individual
fields one by one. On processors that require alignment, that is
probably the only way to go about things.


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If builders built buildings the way programmers wrote programs,
 then the first woodpecker that came along would destroy
 civilisation." -- Gerald Weinberg
0
Rudy
12/27/2008 10:51:57 AM
Dan Barclay wrote:

> > Actually it is true. For example, integer operations on  32-bit
> > CPUs a 32-bit integer has better performance than does a 8, 16 or
> > 64-bit  integer.
> 
> No, the statement "According to all computer languages worldwide,
> Integer ( and Cardinal) is already a native integer that represents
> the CPU register..." is not true.

Certainly not. Just imagine using 8 bit integers on an 8 bit machine.
My 8 bit Beeb even had 32 bit integers by default.

And apparently on the x86-64 in 64 bit mode, 32 bits perform just as
well as 64 bits, unlike 16 bits or 8 bits. This is probably because the
AMD64 was designed to be used in "long mode", which means that 32 bit
integers would still be the default, even in 64 bit mode.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Misunderstandings and neglect create more confusion in this 
 world than trickery and malice. At any rate, the last two are 
 certainly much less frequent." -- Goethe, "Werther"
0
Rudy
12/27/2008 10:58:19 AM
John Cash wrote:

> "Dan Barclay" wrote:
> > "John Cash" wrote:
> > 
> > The C language defines the integer as being a variable size.
> > Actually it does specify a minimum size, but the upper size can
> > reflect the CPU and still be within the language definition.
> 
> Well, not exactly... ;-)
> 
> Actually std C (K&R p34) defines the basic data type "int an integer, 
> typically the natural size of an integer on the host machine."

Well, then define "natural". Those days, most processors were still 8
bit, and I can't imagine C using 8 bit ints on any system. Since those
days, most address registers were 16 bit, and integers and pointers
were still interchangeable, I assume 16 bit was considered "natural",
even on an 8 bit machine, i.e. one with an 8 bit accumulator or
accumulators.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A great many people think they are thinking when they are
 merely rearranging their prejudices." -- William James
0
Rudy
12/27/2008 11:02:08 AM
Ralf Stocker wrote:

> Back to the question. According to the rule from Help (see below), 
> Integer and Cardinal would become 64 bit in Delphi 2010.

Not if you consider the way the latest 64 bitters (x86-64) are
designed. They are designed to use 32 bit integers, and 32 bit integers
are just as fast as 64 bit ones.


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"I have often regretted my speech, never my silence."
 -- Xenocrates (396-314 B.C.)
0
Rudy
12/27/2008 11:03:49 AM
Rudy Velthuis (TeamB) wrote:

> Brian Evans wrote:
> 
> > By the way, 32-bit integers execute at full speed when you're
> > running in 64-bit mode, so unless you need the extra bits for some
> > application-specific reason, you should stick to 32-bit ones.
> 
> Thanks, that is what I expected. So using 32 bit instead of 64 bit has
> no obvious disadvantages, but saves us quite a lot of memory.

Especially in L1-L2-L3 cashes.

Can anybody say is there any additional performance penalty of using
8-bit or 16-bit data instead of 32-bit when data is already in the
cash(es) ?

-- 
Alex
0
Alex
12/27/2008 12:29:45 PM
"Pieter Zijlstra" quotes Allen Bauer as

> However in D2007, they're actually broken in that
> SizeOf(NativeInt) = SizeOf(Int64) :-(. We fixed this
> for Tiburon, SizeOf(NativeInt) = SizeOf(Integer)

If running Win32 on a 64bit CPU, would that be broken?

IOW, if
 on a 64bit CPU running a Win32 you get nativeInt = 32 bit
 on a 64bit CPU running a Win64 you get nativeInt = 64 bit

then NativeInt isn't being determined by the CPU, and since in Win64 an 
Integer is 32bits, it's not being determined by the OS integer.

So is sizeof(NativeInt) = sizeof(pointer) always true? Is NativeInt simply a 
non-typesafe pointer (or in different terms a generic integral type 
guaranteed compatible with pointer assignment)?

That would align with Barry's statement that the VCL component Tag property 
is being made a NativeInt.

bobD
0
Robert
12/27/2008 2:28:59 PM
"Rudy Velthuis (TeamB)" wrote
>
> They choose the size that makes most sense and then document it.

there's a vase difference between
  "NativeInt is X because we thought it made the most sense."
and
  "NativeInt conceptually is a generic integral type intended to be 
assignment compatible with pointers. So for any platform, sizeof(NativeInt) 
= sizeof(pointer).

The first is all you've offered so far.

The latter clearly distinquishes NativeInt functionally from Integer, and 
from all the fundamental types. It's explicable, and non-redundant.

I'd just like to know if it's right--or if it isn't, what is right. 
Conceptual clarity is all.

bobD
0
Robert
12/27/2008 2:40:58 PM
> I would say, a type is Generic when its size matches the cpu register 
> (best performance, no masking etc). This is OS independent.

Right, but that doesn't mean that integers and pointers necessarily have the 
same size. On Intel 32 bit CPUs both are 32 bit (like eax and ebp). But that's 
not a must. On Intel 16 bit CPUs integers were 16 bit (like ax) and far pointers 
were 20 bit represented as 32 bit (like ss:bp). Many programming languages for 
Intel 16 bit CPUs, like Turbo Pascal, are using 16 bit pointers, storing just 
the offset (near pointer) to simplify matters. But it would be possible to have 
another pointer type for segment and offset as well.

Programming for Intel 64 bit CPUs of course 64 bit registers like rax can be 
used for integer arithmetic. But just like you can use 16 and 8 bit registers 
(like ax and al) on 32 bit CPUs, it's perfectly legal to use 32 bit registers 
(like eax) on 64 bit CPUs as well. Using 64 bit registers isn't necessarily 
faster than using 32 bit registers. Usually there is a huge benefit for 
transferring data, using a 64 register once is better than using a 32 bit 
register twice. But for this purpose even on 32 bit machines wider registers are 
used (like the 64 bit MMX registers). For other purposes, like adding two 
relatively small numbers, there isn't really any need for 64 bit.

Making use of the complete 64 bit address space however a 64 bit pointer type is 
required. That means that the "best" integer type doesn't need to have the same 
size as a pointer.

-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
12/27/2008 2:41:14 PM
"Rudy Velthuis (TeamB)" wrote:
> John Cash wrote:
>>
>> Actually std C (K&R p34) defines the basic data type "int an integer,
>> typically the natural size of an integer on the host machine."
>
> Well, then define "natural". Those days, most processors were still 8
> bit, and I can't imagine C using 8 bit ints on any system. Since those
> days, most address registers were 16 bit, and integers and pointers
> were still interchangeable, I assume 16 bit was considered "natural",
> even on an 8 bit machine, i.e. one with an 8 bit accumulator or
> accumulators.

The C language was originally designed for and implemented on the UNIX 
operating system on the DEC PDP-11 computer by Dennis Ritchie. The (1970) 
PDP-11 word size was 16 bits and it had eight general purpose 16-bit 
registers. The older (1965) PDP-8 had a 12 bit word size.

If you lookup the referenced (1978) K&R page I quoted from it shows the DEC 
PDP-11 integer size is 16 bits, Honeywell 6000 is 36 bits, IBM 370 is 32 
bits and Interdata 8/32 is 32 bits.
0
John
12/27/2008 3:31:58 PM
<<You:
Integer: generic type, size determined by standard 'Integer' definition
of OS
>>

<<Me:
Size determined by compiler writers, but based on default integer sizes
of the OS or platform.
>>

<<You:
Unless one can say how they determine it
>>

<<Me: 
They choose the size that makes most sense and then document it.
>>

<<You:
there's a vase difference between "NativeInt is X because we thought it
made the most sense."
>>

Huh? I am and was talking about the generic Integer, not about
NativeInt.

Like was said before, on an 8 bit system, NativeInt ought to be 8 bit,
but most generic integers were/are 16 bit.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Criticism is prejudice made plausible." 
 -- Henry Louis Mencken (1880-1956)
0
Rudy
12/27/2008 4:38:21 PM
Alex Belo wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > Brian Evans wrote:
> > 
> > > By the way, 32-bit integers execute at full speed when you're
> > > running in 64-bit mode, so unless you need the extra bits for some
> > > application-specific reason, you should stick to 32-bit ones.
> > 
> > Thanks, that is what I expected. So using 32 bit instead of 64 bit
> > has no obvious disadvantages, but saves us quite a lot of memory.
> 
> Especially in L1-L2-L3 cashes.
> 
> Can anybody say is there any additional performance penalty of using
> 8-bit or 16-bit data instead of 32-bit when data is already in the
> cash(es) ?

I assume that even accessing 8 and 16 bit registers requires an extra
size prefix, which means even that costs some time.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Most of you are familiar with the virtues of a programmer.
 There are three, of course: laziness, impatience, and hubris."
 -- Larry Wall
0
Rudy
12/27/2008 4:39:38 PM
John Cash wrote:

> > Well, then define "natural". Those days, most processors were still
> > 8 bit, and I can't imagine C using 8 bit ints on any system. Since
> > those days, most address registers were 16 bit, and integers and
> > pointers were still interchangeable, I assume 16 bit was considered
> > "natural", even on an 8 bit machine, i.e. one with an 8 bit
> > accumulator or accumulators.
> 
> The C language was originally designed for and implemented on the
> UNIX operating system on the DEC PDP-11 computer by Dennis Ritchie.
> The (1970) PDP-11 word size was 16 bits and it had eight general
> purpose 16-bit registers. The older (1965) PDP-8 had a 12 bit word
> size.

But C was used on many other computers, and one would assume that int
would still be at least 16 bit on most, even if they were 8 bit systems.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"There are, it has been said, two types of people in the world. 
 There are those who, when presented with a glass that is exactly 
 half full, say: this glass is half full. And then there are 
 those who say: this glass is half empty. The world belongs, 
 however, to those who can look at the glass and say: What's up 
 with this glass? Excuse me? Excuse me? This is my glass? I don't 
 think so. My glass was full! And it was a bigger glass!"
 -- Terry Pratchett, "The Truth"
0
Rudy
12/27/2008 4:41:06 PM
Robert Dawson wrote:

> IOW, if
> on a 64bit CPU running a Win32 you get nativeInt = 32 bit
> on a 64bit CPU running a Win64 you get nativeInt = 64 bit
> 
> then NativeInt isn't being determined by the CPU, and since in Win64
> an Integer is 32bits, it's not being determined by the OS integer.

NativeInt is the size of a register, so in 64 bit mode it should be 64
bit, which means it IS defined by the CPU. When running in 32 bit mode,
32 bit is the largest possible register you can get, and that is
defined by the CPU too.

So it IS determined by the CPU. What is so complicated about that?
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"You'll notice that Nancy Reagan never drinks water when Ronnie
 speaks." -- Robin Williams.
0
Rudy
12/27/2008 4:45:34 PM
Ralf Stocker wrote:

> > IOW, there is nothing in the definition of "generic" that says it
> > should be register size.
> 
> I would say, a type is Generic when its size matches the cpu register 
> (best performance, no masking etc). This is OS independent.

No, it is not OS independent at all. If you run Win32 on a 64 bit CPU
like a Core 2, register size is 32 bit and there is, AFAIK, no way you
can address the full RAX, RBX, etc. So the OS most definitely decides
what integer size is.

And we already learned that even in 64 bit mode, performance of 32 bit
registers is not worse than that of 64 bit registers.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The de facto role of the US armed forces will be to keep the
 world safe for our economy and open to our cultural assault."
 -- Major Ralph Peters, US Military
0
Rudy
12/27/2008 4:51:01 PM
"Rudy Velthuis (TeamB)" wrote:
> John Cash wrote:
>>
>> The C language was originally designed for and implemented on the
>> UNIX operating system on the DEC PDP-11 computer by Dennis Ritchie.
>> The (1970) PDP-11 word size was 16 bits and it had eight general
>> purpose 16-bit registers. The older (1965) PDP-8 had a 12 bit word
>> size.
>
> But C was used on many other computers, and one would assume that int
> would still be at least 16 bit on most, even if they were 8 bit systems.

I believe that at the time the K&R book was written, C had only been 
implemented on the four machines they listed. However, if for a moment you 
get off your "absolutist horse", you might understand why the word 
"typically" was included in their definition of an integer and then you 
would realize it encompasses having 16 bit integers on 8 bit host. ;-)
0
John
12/27/2008 9:15:17 PM
John Cash wrote:

> "Rudy Velthuis (TeamB)" wrote:
> > John Cash wrote:
> > > 
> >> The C language was originally designed for and implemented on the
> >> UNIX operating system on the DEC PDP-11 computer by Dennis Ritchie.
> >> The (1970) PDP-11 word size was 16 bits and it had eight general
> >> purpose 16-bit registers. The older (1965) PDP-8 had a 12 bit word
> >> size.
> > 
> > But C was used on many other computers, and one would assume that
> > int would still be at least 16 bit on most, even if they were 8 bit
> > systems.
> 
> I believe that at the time the K&R book was written, C had only been 
> implemented on the four machines they listed. However, if for a
> moment you get off your "absolutist horse", you might understand why
> the word "typically" was included in their definition of an integer
> and then you would realize it encompasses having 16 bit integers on 8
> bit host. ;-)

You must be mistaken. I am not the absolutist here. The absolutists
here are the ones who think that on Win64, the generic type integer
MUST be 64 bit, or otherwise it would not be generic anymore.

And that is why I fully agree with their use of the word "typically".

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Support your local Search and Rescue unit -- get lost."
 -- Unknown
0
Rudy
12/27/2008 9:24:03 PM
"Rudy Velthuis (TeamB)" wrote:
> 
> You must be mistaken. I am not the absolutist here.

Damn, how could I have ever reached that conclusion? ;-))
0
John
12/27/2008 10:21:04 PM
John Cash wrote:

> "Rudy Velthuis (TeamB)" wrote:
> > 
> > You must be mistaken. I am not the absolutist here.
> 
> Damn, how could I have ever reached that conclusion? ;-))

I have no idea. I am as flabbergasted as you seem to be. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Every day I get up and look through the Forbes list of the 
 richest people in America. If I'm not there, I go to work."
 -- Robert Orben
0
Rudy
12/27/2008 10:54:28 PM
Robert Dawson wrote:

> "Pieter Zijlstra" quotes Allen Bauer as
> 
> > However in D2007, they're actually broken in that
> > SizeOf(NativeInt) = SizeOf(Int64) :-(. We fixed this
> > for Tiburon, SizeOf(NativeInt) = SizeOf(Integer)
> 
> If running Win32 on a 64bit CPU, would that be broken?

No you would be running in 32bit compatible mode.

> So is sizeof(NativeInt) = sizeof(pointer) always true? 

That seems to be the idea behind it.

-- 
Pieter

"The full use of your powers along lines of excellence."
-- definition of "happiness" by John F. Kennedy (1917-1963)
0
Pieter
12/27/2008 11:57:09 PM
"Rudy Velthuis (TeamB)" wrote
>
> So it IS determined by the CPU. What is so complicated about that?

Well, the fact that the CPU doesn't change, while the size of NativeInt does 
would seem to suggest something other than a fixed 1::1 relationship ...

I'm leaning to the view that NativeInt is set by the size of the logical 
memory space--i.e., NativeInt is whatever size a memory pointer is.

Or if you really want to claim the CPU, call it the effective size of the 
Instruction Pointer register.

In any case, would be nice if CodeGear clarified.

bobD
0
Robert
12/28/2008 4:05:38 AM
>> So it IS determined by the CPU. What is so complicated about that?

"Robert Dawson" wrote

> Well, the fact that the CPU doesn't change, while the size of NativeInt does 
> would seem to suggest something other than a fixed 1::1 relationship ...
> ...
> In any case, would be nice if CodeGear clarified.

Why not change the name to something like "NativeInt2009"?  <g>  
And why not give warnings when programmers attempt to use
in packed records, types that can change? 

--JohnH
0
John
12/28/2008 11:06:48 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > So it IS determined by the CPU. What is so complicated about that?
> 
> Well, the fact that the CPU doesn't change

The mode it runs in changes. It would be quite silly to expect 64 bit
registers when running in 32 bit mode. So in 32 bit mode (which is what
you use when you run a 32 bit OS), registers are 32 bit, not 64 bit,
and so NativeInt is also 32 bit. There are also fewer registers
available then in 64 bit mode.

This is not rocket science, is it? 
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A non-virtual function says, you have to do this and you must
 do it this way. A virtual function says you have to do this,
 but you don't have to do it this way. That's their fundamental
 difference." -- Scott Meyers
0
Rudy
12/28/2008 12:46:44 PM
John Herbster wrote:

> >> So it IS determined by the CPU. What is so complicated about that?
> 
> "Robert Dawson" wrote
> 
> > Well, the fact that the CPU doesn't change, while the size of
> > NativeInt does would seem to suggest something other than a fixed
> > 1::1 relationship ...  ...
> > In any case, would be nice if CodeGear clarified.
> 
> Why not change the name to something like "NativeInt2009"? 

Why? NativeInt should reflect the size of the registers used by the
processor for the given target. If the target is 64 bit, it should be
64 bit as well, and if the target is 32 bit, it should be 32 bit.

That is the only way it makes sense.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Everything has been figured out, except how to live."
 -- Jean-Paul Sartre (1905-1980)
0
Rudy
12/28/2008 12:49:54 PM
> NativeInt should reflect the size of the registers used by the
> processor for the given target. ... 
> That is the only way it makes sense.

Ah so!  I guess that is where we came with the names 
Delphi16, Delphi32, and Delphi64.  <G> --JohnH
0
John
12/28/2008 2:12:42 PM
John Herbster wrote:

> > NativeInt should reflect the size of the registers used by the
> > processor for the given target. ... 
> > That is the only way it makes sense.
> 
> Ah so!  I guess that is where we came with the names 
> Delphi16, Delphi32, and Delphi64.  <G> --JohnH

I don't understand.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The best is the enemy of the good." -- Voltaire
0
Rudy
12/28/2008 2:19:15 PM
John Herbster wrote:

> And why not give warnings when programmers attempt to use
> in packed records, types that can change?

A compiler should not issue warnings for perfectly valid, unambiguous
code.

But it is a know fact that if you want your types to remain the same
size throughout versions and platforms, you should use fundamental
(i.e. fixed size) types like Longint, Word or AnsiChar, and not generic
types like Integer, Cardinal or Char.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If you gaze long into an abyss, the abyss will gaze back into 
 you." -- Friedrich Nietzsche (1844-1900)
0
Rudy
12/28/2008 2:27:53 PM
"Rudy Velthuis (TeamB)" wrote

> Why? NativeInt should reflect the size of the registers used by the
> processor for the given target. If the target is 64 bit, it should be
> 64 bit as well, and if the target is 32 bit, it should be 32 bit.

What you don't seem to consider is that Delphi already has a generic 
integral type that adjusts to the 'platform'. It's called an Integer. We now 
have two such types.

Distinguishing them requires that their respective bases of adjustment be 
clarified, since they're not redundant but divergent. The simple statement 
that they both vary with CPU/register size is patently insufficient.

Since NativeInt is new, it needs a clear definition of exactly what it's 
intended to track so that people can adopt it appropriately. It appears to 
me to be intended to track memory address space, so that the size of a 
NativeInt is guaranteed to be sizeof(pointer). If so, that needs said.

In the case of Integer, it's failure to become 64bit on a 64bit platform is 
noteworthy on several fronts:

First, the idea that '32bit is just as fast as 64bit' on current CPUs is 
more an accident of recent history than a technical consideration: I don't 
think it's true of the Itanium (IA-64), for example. So the fact that 
current 64bit CPUs support full-speed 32bit use depends arguably on a 
transition-kludge--there's no reason why it has to be so, and it may not 
always be the case. Once the 64bit platform is the norm, we can easily 
imagine Intel removing the special 32bit handling in a future revision.

Second, it's been repeatedly claimed that defaulting to 64bit Integers would 
simply be a waste in most cases: actual need for the larger integer size is 
relatively limited. But notice that this argument has nothing whatsoever to 
do with the hardware--if true, it will remain true going forward, because 
it's an argument of what we might call 'problem domain' application, not of 
'solution domain' CPU technology. It suggests that Integer is indeed 
becoming a fixed type--that it's in the process of topping out.

bobD
0
Robert
12/28/2008 3:09:31 PM
"Rudy Velthuis (TeamB)" wrote
>
> This is not rocket science, is it?

No. Neither is it necessary. The mere existence of a 32bit mode is simply a 
matter of AMD having won a round against Intel--something they now seem 
unlikely to repeat.

bobD
0
Robert
12/28/2008 3:12:24 PM
Robert Dawson wrote:

> What you don't seem to consider is that Delphi already has a generic
> integral type that adjusts to the 'platform'. It's called an Integer.
> We now have two such types.

Just use the words "architecture" and "platform" for the
NativeInt/Integer definition:

Integer => platform (OS defines the size)
NativeInt => architecture (CPU defines the size)


-- 
Regards,

Andreas Hausladen
0
Andreas
12/28/2008 4:03:32 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> 
> > Why? NativeInt should reflect the size of the registers used by the
> > processor for the given target. If the target is 64 bit, it should
> > be 64 bit as well, and if the target is 32 bit, it should be 32 bit.
> 
> What you don't seem to consider is that Delphi already has a generic
> integral type that adjusts to the 'platform'. It's called an Integer.
> We now have two such types.

Yes, and they have different meanings. NativeInt is the type that
reflects the maximum usable register size. Integer reflects the default
type chosen by the compiler writers, for various reasons.

I would not call NativeInt "generic", since, as the name already says,
generic types (Cardinal, Integer, Char) are meant to be used when the
specific size does not really matter. Their sizes MAY change with the
platform, but they DON'T HAVE TO. Their size is chosen by the compiler
writers and is generally the most convenient choice for general
purposes. Often, this will reflect the register size, but IT DOESN'T
HAVE TO, just think of 64 bit systems (where 64 bit integers would be
overkill) or 8 bit systems (where 8 bit integers would be far too
small).

For NativeInt, size is the only reason that it exists, IOW, it exists
so you have a type that can hold register size values, if that is
needed, and so you can find out the size of such a register (in bytes).

So NativeInt is a third kind, a system-dependent type. This is not
fixed, since it changes with the system (Win32, Win64), but it is not
generic either.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"God is love, but get it in writing." -- Gypsy Rose Lee.
0
Rudy
12/28/2008 4:40:21 PM
Andreas Hausladen wrote:

> Just use the words "architecture" and "platform" for the
> NativeInt/Integer definition:
> 
> Integer => platform (OS defines the size)

I don't even think that the OS does. The compiler writers do, and it
makes sense that they tend to use the same sizes as other compilers do
on the same platform. IOW, the OS is a factor in the definition of the
size, but not necessarily the sole one.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"There is no sincerer love than the love of food."
 -- George Bernard Shaw (1856-1950)
0
Rudy
12/28/2008 4:42:35 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > This is not rocket science, is it?
> 
> No. Neither is it necessary. The mere existence of a 32bit mode is
> simply a matter of AMD having won a round against Intel--something
> they now seem unlikely to repeat.

The mere existence of a 32 bit mode means that you can run 32 bit
Windows on an x86-64 like a Core 2, without any problems or without
having to update all your software and/or hardware drivers. I think
that is a Good Thing(tm).

But I don't quite see what is "necessary" about this entire discussion.

Using Int64 as the standard integer is pure nonsense. For most
purposes, even 32 bit are overkill, but they are at least faster than
16 or 8 bit items. On 64 bit systems, 32 bit integers are just as fast
as 64 bit ones, so I see no good reason to use 64 as standard integer
size.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The competent programmer is fully aware of the limited size of 
 his own skull. He therefore approaches his task with full 
 humility, and avoids clever tricks like the plague."
 -- Edsger W. Dijkstra, EWD340
0
Rudy
12/28/2008 4:48:36 PM
"Andreas Hausladen" wrote
>
> Integer => platform (OS defines the size)
> NativeInt => architecture (CPU defines the size)

And do those satisfy you as formal technical definitions? We simply 
attribute each to random deus ex machina influences for which no account is 
necessary?

Perhaps there's something to this:
"[...] the single biggest predictor of likely aptitude for programming is a 
deep comfort with meaninglessness"

  - http://www.boingboing.net/2008/12/12/comfort-with-meaning.html

bobD
0
Robert
12/28/2008 4:52:12 PM
Rudy Velthuis (TeamB) wrote:
> Robert Dawson wrote:
> 
>> "Rudy Velthuis (TeamB)" wrote
>>> This is not rocket science, is it?
>> No. Neither is it necessary. The mere existence of a 32bit mode is
>> simply a matter of AMD having won a round against Intel--something
>> they now seem unlikely to repeat.
> 
> The mere existence of a 32 bit mode means that you can run 32 bit
> Windows on an x86-64 like a Core 2, without any problems or without
> having to update all your software and/or hardware drivers. I think
> that is a Good Thing(tm).
> 
> But I don't quite see what is "necessary" about this entire discussion.
> 
> Using Int64 as the standard integer is pure nonsense. For most
> purposes, even 32 bit are overkill, but they are at least faster than
> 16 or 8 bit items. On 64 bit systems, 32 bit integers are just as fast
> as 64 bit ones, so I see no good reason to use 64 as standard integer
> size.

Why is it a overkill??? Int64 is the *natural* (Generic Integer) type on 
Win64. 32 bit processing is just implemented for compatibility reasons 
in the CPU.
0
Ralf
12/28/2008 6:46:08 PM
Rudy,

| This is not rocket science, is it?

Perhaps to those not familiar with hardware machine architecture and
assembly coding it may appear as such.  ;-)

-- 

   Q

12/28/2008 11:01:07

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/28/2008 7:03:52 PM
"Ralf Stocker"
> Why is it a overkill??? Int64 is the *natural* (Generic Integer) type on
> Win64. 32 bit processing is just implemented for compatibility reasons
> in the CPU.

32-bit processing on a 64-bit CPU is not for compatibility, it is a 
neccessity.
A 64-bit CPU should be able to handle all data types with varying sizes. 
(8-bit,16-bit, 32 bit and 64-bit)
0
farshad
12/28/2008 7:03:54 PM
>> And why not give warnings when programmers attempt to use
>> in packed records, types that can change?

> A compiler should not issue warnings for perfectly valid, unambiguous
> code.
> But it is a [known] know fact that if you want your types to remain the
> same size throughout versions and platforms, you should use fundamental
> (i.e. fixed size) types like Longint, Word or AnsiChar, and not generic
> types like Integer, Cardinal or Char.

If only it *were* well known or the compilers *did* give warnings when 
the programmers attempted to use in packed records, types that changed, 
it would have saved a lot of programmers a lot of time and trouble.  

--JohnH
0
John
12/28/2008 7:44:30 PM
Farshad Mohajeri wrote:
> "Ralf Stocker"
>> Why is it a overkill??? Int64 is the *natural* (Generic Integer) type on
>> Win64. 32 bit processing is just implemented for compatibility reasons
>> in the CPU.
> 
> 32-bit processing on a 64-bit CPU is not for compatibility, it is a 
> neccessity.
> A 64-bit CPU should be able to handle all data types with varying sizes. 
> (8-bit,16-bit, 32 bit and 64-bit)


Nevertheless I would emphasize the term "compatibility reasons"
0
Ralf
12/28/2008 8:15:56 PM
John Herbster wrote:

> > But it is a [known] know fact that if you want your types to remain
> > the same size throughout versions and platforms, you should use
> > fundamental (i.e. fixed size) types like Longint, Word or AnsiChar,
> > and not generic types like Integer, Cardinal or Char.
> 
> If only it were well known

It is well known.

> or the compilers did give warnings

Like I said: no warnings for valid, unambiguous code.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A low voter turnout is an indication of fewer people going to 
 the polls." -- George W. Bush
0
Rudy
12/28/2008 9:23:31 PM
Ralf Stocker wrote:

> > Using Int64 as the standard integer is pure nonsense. For most
> > purposes, even 32 bit are overkill, but they are at least faster
> > than 16 or 8 bit items. On 64 bit systems, 32 bit integers are just
> > as fast as 64 bit ones, so I see no good reason to use 64 as
> > standard integer size.
> 
> Why is it a overkill???

<sigh> I thought that was made clear by now, but OK, here I'll explain
once again. There is no need to use 8 bytes for an integer when in
probably 99% of the situations where integers/enums/etc. are used 4
bytes are not even used to their full extent.

And even on an x86-64 in 64 bit mode, 32 bits are just as fast as 64,
so there is ab-so-lute-ly no need to use 64 bits as default integer.
For the very rare occasions where 64 bits make sense, you can always
use Int64.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"C makes it easy to shoot yourself in the foot; C++ makes it 
 harder, but when you do, it blows away your whole leg."
 -- Bjarne Stroustrup
0
Rudy
12/28/2008 9:29:54 PM
Ralf Stocker wrote:

> Why is it a overkill??? Int64 is the natural (Generic Integer) type
> on Win64. 32 bit processing is just implemented for compatibility
> reasons in the CPU.

No, not at all. If that were the case, it would be slightly slower,
juts like 16 bit and 8 bit are. But that is not the case at all. 64 bit
integers ARE PURE OVERKILL, since they are NOT NEEDED in the vast
mojority of cases where integers/enums/etc. are used. For many
situations, 32 bits are already overkill, but they are at least faster
than 16 or 8 bit accesses.

And note that 64 bit integers require 8 bytes of storage each. If you
have many of them (and I assume most programs have many integers), you
are wasting an enormous amount of memory, and it will probably also be
reflected in more frequent cache misses.

And the generic integer type in Win64 is 32 bit, BTW. Probably because
AMD, Intel and Microsoft thought of the same considerations.

Oh, there may be times when 64 bit integers would start making sense,
but those times have not arrived yet.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"It is better to have a permanent income than to be fascinating."
 -- Oscar Wilde (1854-1900)
0
Rudy
12/28/2008 9:38:56 PM
Ralf Stocker wrote:

> Farshad Mohajeri wrote:
> > "Ralf Stocker"
> >> Why is it a overkill??? Int64 is the natural (Generic Integer)
> type on >> Win64. 32 bit processing is just implemented for
> compatibility reasons >> in the CPU.
> > 
> > 32-bit processing on a 64-bit CPU is not for compatibility, it is a 
> > neccessity.
> > A 64-bit CPU should be able to handle all data types with varying
> > sizes.  (8-bit,16-bit, 32 bit and 64-bit)
> 
> 
> Nevertheless I would emphasize the term "compatibility reasons"

Then you would be wrong. I am pretty sure that the choice of 32 bit was
deliberate. AMD64 were designed to run in long mode, which means the
default integer is 32 bit, not 64 bit.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Incrementing C by 1 is not enough to make a good object-oriented
 language."  -- M. Sakkinen
0
Rudy
12/28/2008 9:40:24 PM
Quentin Correll wrote:

> Rudy,
> 
> >  This is not rocket science, is it?
> 
> Perhaps to those not familiar with hardware machine architecture and
> assembly coding it may appear as such.  ;-)

Well, I assume that those who want to discuss this in depth have enough
knowledge of the matter, otherwise they would not even know what they
were talking about. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Military justice is to justice what military music is to music."
 -- Groucho Marx
0
Rudy
12/28/2008 9:42:04 PM
Rudy,

| Well, I assume that those who want to discuss this in depth have
| enough knowledge of the matter, otherwise they would not even know
| what they were talking about. <g>

Uhhh,...  I think I'll not make further comment.  ;-)

Happy New Year!


-- 

   Q

12/28/2008 13:44:25

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/28/2008 9:46:20 PM
Quentin Correll wrote:

> Rudy,
> 
> >  Well, I assume that those who want to discuss this in depth have
> >  enough knowledge of the matter, otherwise they would not even know
> | what they were talking about. <g>
> 
> Uhhh,...  I think I'll not make further comment.  ;-)
> 
> Happy New Year!

Far too early! <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If you want a product with certain characteristics, you must
 ensure that the team has those characteristics before the
 product's development." 
 -- Jim McCarthy and Michele McCarthy - Software for your Head
0
Rudy
12/28/2008 9:48:56 PM
"Rudy Velthuis (TeamB)" wrote

> generic types (Cardinal, Integer, Char) are meant to be used when
> the specific size does not really matter. Their sizes MAY change with
> the platform, but they DON'T HAVE TO.

So all your code will work perfectly fine if Integer was defined as 4 bits 
in the next version of Delphi? Somehow I doubt it.

Personally I don't think I've ever written a line of code where you could 
truly say 'size does not really matter.' Integral types are chosen for a 
variety of reasons: range/capacity, performance, external-system 
compatibility, etc. Generally the glib 'size doesn't matter' is actually two 
main considerations: (1) it's big enough to be adequate for the purpose at 
hand, and (2) small enough that choosing a smaller type doesn't offer a 
significant advantage. And the so-called size indifference is strictly one 
way: no one ever chooses an Integer type with the understanding that it 
might get arbitrarily smaller.

> Their size is chosen by the compiler
> writers and is generally the most convenient choice

You keep going in circles: chosen on what basis? And 'convenient' doesn't 
mean anything until you specify what the standards of convenience are.

> (where 64 bit integers would be overkill)
And you keep missing the obvious point that it's incredibly common to see 
32bit integers used where smaller declarations would suffice. We've all done 
it for years, but nobody's apparently concerned about 32bits being 
'overkill.' Clearly, some fundamental pressures have changed.

Consider this analogy: Suppose we can specify that, on standard Intel 32bit 
CPUs, there is no performance difference whatsoever between 16 and 32 bit 
integers. IOW, we could have defined Integer in win32 as being the same as 
Smallint, and not suffered any performance disadvantage.

Would it have made sense to do so? If not, why not?

bobD
0
Robert
12/28/2008 10:50:35 PM
"Rudy Velthuis (TeamB)" wrote
>
> I don't even think that the OS does.

Well, it does in the sense that the win64 API specifies call params of a 
certain size, and documents them as being Integers.

bobD
0
Robert
12/28/2008 10:52:39 PM
"Rudy Velthuis (TeamB)" wrote
>
> But I don't quite see what is "necessary" about this entire discussion.

For my part, I'd like to prompt some formal definitions of Integer and 
NativeInt from Allen, Barry and Co., since the long-in-the-tooth help file 
discussions of generic and fundamental types is outdated in the face of two 
different and distinct 'generic' integral types.

Then too, given that there is a meaningful distinction between Integer and 
NativeInt, I don't think it does anyone any harm to test their understanding 
of what these types are intended to incapsulate, how they differ, and what 
their likely evolution might be. We have to use these types every day, and 
CodeGear has to determine where in makes sense to 'adjust' the VCL to 
them--being clear on what they mean and their intended functions might be an 
advantage.

The reasons for your participation in the conversation escape me.

> Using Int64 as the standard integer is pure nonsense. For most
> purposes, even 32 bit are overkill,

Which leaves open the question of why 64bit overkill matters, and 32bit 
overkill doesn't.

> On 64 bit systems, 32 bit integers are just as fast
> as 64 bit ones,

But if not actually faster, what is their advantage? It's not like you're 
paying the CPU by the bit. Anyone concerned by the fact that a Boolean 
occupies more than a bit? If I can fill a register in one operation, what's 
the sudden concern that all possible values aren't actually needed?

bobD
0
Robert
12/28/2008 11:19:54 PM
Rudy,

| Far too early! <g>

<setting watch>

-- 

   Q

12/28/2008 16:13:18

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/29/2008 12:14:32 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > I don't even think that the OS does.
> 
> Well, it does in the sense that the win64 API specifies call params
> of a certain size, and documents them as being Integers.

Most of them are documented as DWORDs, LPARAMs, UINTs, INTPTRs, or
such, and these can be seen as fixed size items. You'll hardly see
"int" being used as a parameter to a Windows API function, or as a
field of a Windows API structure.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Early to rise and early to bed. Makes a male healthy, wealthy 
 and dead." -- James Thurber.
0
Rudy
12/29/2008 1:34:39 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> 
> > generic types (Cardinal, Integer, Char) are meant to be used when
> > the specific size does not really matter. Their sizes MAY change
> > with the platform, but they DON'T HAVE TO.
> 
> So all your code will work perfectly fine if Integer was defined as 4
> bits in the next version of Delphi? Somehow I doubt it.

Most of my code is written in a platform-independent way. That is a
habit I acquired when D7 started complaining about certain constructs,
in preparation for .NET. So I avoid pointers where I can, my code
hardly assumes that a Char is 1 byte, I seldom modify string internals
using PChar (do not confuse this with a PChar cast to call a WinAPI
function), but use indexing instead, etc.

So 99% of my code will most definitely work perfectly fine after a
recompilation, and the few lines of code that won't (pointer
arithmetic) will certainly give a warning or error. The above is also
why my code had no big problems when recompiled in D2009.

But I don't quite understand WHY it should be a problem? 

The only problems that can arise are when integer types are used to
store pointers, when Longint or Longword casts are used to perform
pointer arithmetic, or when records that contain pointers (a most
definite no-no, so you won't see my code do that) are stored directly
to a disk.

I hardly do such things, except for the pointer arithmetic, which is
sometimes unavoidable. But even then, I generally use SizeOf(Pointer).

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Inanimate objects can be classified scientifically into three 
 major categories; those that don't work, those that break down 
 and those that get lost." -- Russell Baker.
0
Rudy
12/29/2008 1:47:18 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > But I don't quite see what is "necessary" about this entire
> > discussion.
> 
> For my part, I'd like to prompt some formal definitions of Integer
> and NativeInt from Allen, Barry and Co.,

<sigh> Aren't they bloody obvious?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"You'll notice that Nancy Reagan never drinks water when Ronnie
 speaks." -- Robin Williams.
0
Rudy
12/29/2008 1:48:42 AM
Quentin Correll wrote:

> Rudy,
> 
> | Far too early! <g>
> 
> <setting watch>

<g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"They laughed when I said I'd be a comedian. They aren't 
 laughing now."
0
Rudy
12/29/2008 1:53:40 AM
"Rudy Velthuis (TeamB)" wrote
>>
>> For my part, I'd like to prompt some formal definitions of Integer
>> and NativeInt from Allen, Barry and Co.,
>
> <sigh> Aren't they bloody obvious?

Your opinions (integers are whatever the compiler writers decide, NativeInts 
are whatever the 'register' size is) are bloody obvious.

Actual formal definitions and use rationales are not in evidence at all. 
Though I think I have reasonable guesses.

bobD
0
Robert
12/29/2008 3:03:32 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > > 
> > > For my part, I'd like to prompt some formal definitions of Integer
> > > and NativeInt from Allen, Barry and Co.,
> > 
> ><sigh> Aren't they bloody obvious?
> 
> Your opinions (integers are whatever the compiler writers decide,
> NativeInts are whatever the 'register' size is) are bloody obvious.

They are not opinions. That describes the situation, and is the only
way it makes sense anyway. Of course the sizes of generic types are not
just chosen out of a whim, so it is not exactly as you describe it.

I really don't see why this is such a problem for you. It IS bloody
obvious that it is how it is and how it makes sense. The compiler
writers are no fools.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"There's no sense being exact about something if you don't even
 know what you're talking about." -- John von Neumann
0
Rudy
12/29/2008 3:27:20 AM
"Rudy Velthuis (TeamB)" wrote
> Of course the sizes of generic types are not
> just chosen out of a whim

Of course not.

> I really don't see why this is such a problem for you.

I never said it was a problem--call it an intellectual/academic curiousity: 
I think knowing the rationales and formal/functional definitions would be 
quite interesting, and perhaps useful. And lord knows it's not like the 
documentation couldn't use an update.

> It IS bloody
> obvious that it is how it is and how it makes sense.

I know it looks like that to you. Are you by any chance familiar with this 
story?
http://ftp.disabilityisnatural.com/email/documents/Ham.pdf

> The compiler
> writers are no fools.

I never said they were, and have no idea why you seem to think you're 
defending anyone. IME, asking somebody brilliant to explain the thinking 
behind a choice produces much more interesting answers than asking a fool.

bobD
0
Robert
12/29/2008 4:28:24 AM
I don't have K&R with me since I'm on the road, but I do 
recall the wording you quote ("typically the natural size" 
etc).  That is descriptive, not specification.  Elsewhere in 
the language definition is the actual specification.  If you 
can put your hands on that I think you'll find the minimum 
size specified.

Dan



"John Cash" <JohnJ@nada.com> wrote in message 
news:59645@forums.codegear.com...
> "Dan Barclay" wrote:
>> "John Cash" wrote:
>>
>> The C language *defines* the integer as being a variable 
>> size.  Actually
>> it does specify a minimum size, but the upper size can 
>> reflect the CPU and
>> still be within the language definition.
>
> Well, not exactly... ;-)
>
> Actually std C (K&R p34) *defines* the basic data type 
> "int an integer,
> typically the natural size of an integer on the host 
> machine."
>
> "In addition there are a number of qualifiers which can be 
> applied to int's:
> short, long and unsigned: short and long refer to the 
> different sizes of
> integers."
>
> "...each compiler is free to interprert short and long as 
> appropriate for
> it's own hardware. About all you should count on is that 
> short is no longer
> than long."
>
>>>> If all language definitions were the same, there would 
>>>> be only one
>>>> computer language.
>>>
>>> That dawg ain't gonna hunt!!
>>
>> Oh, this should be interesting.  Do you claim that all 
>> language
>> definitions are the same?  If not, please explain what 
>> part of the
>> statement you disagree with.
>
> If all definitions were the same in all languages would it 
> be named
> Esperanto... ;-)
0
Dan
12/29/2008 4:33:19 AM
Robert Dawson wrote:

> > It IS bloody
> > obvious that it is how it is and how it makes sense.
> 
> I know it looks like that to you. Are you by any chance familiar with
> this story?
> http://ftp.disabilityisnatural.com/email/documents/Ham.pdf

Probably not, but I will be after I read it. <g>

Well, apparently the mother in law and the wife simply did things
because their mother did it. In the story, it was not obvious at all
why the ends had to be cut, but here, it is quite obvious why integers
remain 32 bit in Win64. I am not irritated by the question because I
don't know the answer. On the contrary, it is obvious for everyone to
see why things are as they are, so the question seems quite futile to
me.

So your story does not apply as an analogy here. On the contrary.

> > The compiler
> > writers are no fools.
> 
> I never said they were, and have no idea why you seem to think you're
> defending anyone.

I am not defending anyone. I am merely wondering why this, which is
soooo obvious, is such an issue for you.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Attention to health is life's greatest hindrance."
 -- Plato (427-347 B.C.)
0
Rudy
12/29/2008 4:38:53 AM
Dan Barclay wrote:

> I don't have K&R with me since I'm on the road, but I do recall the
> wording you quote ("typically the natural size" etc).  That is
> descriptive, not specification.  Elsewhere in the language definition
> is the actual specification.  If you can put your hands on that I
> think you'll find the minimum size specified.

Probably something along the lines of:

  sizeof(short) <= sizeof(int) && sizeof(int) <= sizeof(long)

Note that the actual sizes are implementation-dependent, i.e. decided
by the writers of the compiler. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Computer /nm./: a device designed to speed and automate errors."
 -- From the Jargon File.
0
Rudy
12/29/2008 4:41:38 AM
Rudy Velthuis (TeamB) wrote:

> > > Thanks, that is what I expected. So using 32 bit instead of 64 bit
> > > has no obvious disadvantages, but saves us quite a lot of memory.
> > 
> > Especially in L1-L2-L3 cashes.
> > 
> > Can anybody say is there any additional performance penalty of using
> > 8-bit or 16-bit data instead of 32-bit when data is already in the
> > cash(es) ?
> 
> I assume that even accessing 8 and 16 bit registers requires an extra
> size prefix, which means even that costs some time.

OK, it's true.

What about cashed data rd/wr:

SomeByteBuf[1024];        // already in cach
for(i=0; i<1024; ++i)
{
 int t=SomeByteBuf[i];    // any rd penalty ?
 // ... some computations
 SomeByteBuf[i]=(t & 0xff); // any wr penalty ?
}

In other words: has byte addressing in cash memory any length-dependent
or address-dependent (when address is not on native boundary) latency ?

-- 
Alex
0
Alex
12/29/2008 6:36:04 AM
Hello,

starting with D2009 there are Int32 and UInt32 etc. as well...
Currently Int32 will map simply to integer afaik...

Greetings

Markus
0
Markus
12/29/2008 10:59:07 AM
Hello,

"typically" doesn't mean "always". And yes: C has a very lax type safety
imho.

Greetings

Markus
0
Markus
12/29/2008 11:32:20 AM
"Markus Humm" <markus.humm@freenet.de> wrote

> starting with D2009 there are Int32 and UInt32 etc. as well...

Will that extend to Int8, UInt8, Int16, etc. as well?  

Thx, JohnH
0
John
12/29/2008 11:32:32 AM
"Dan Barclay" wrote :
>I don't have K&R with me since I'm on the road, but I do recall the wording 
>you quote ("typically the natural size" etc).  That is descriptive, not 
>specification.  Elsewhere in the language definition is the actual 
>specification.  If you can put your hands on that I think you'll find the 
>minimum size specified.

Since I'm not aware of the language definition specification you refer to, 
if you would be so kind as to give me the site reference, I'll be more that 
happy to look up it's definition of int. In the mean time I'm going to 
continue to labor under the impression that the the two guys (K&R)who 
"invented" the C language knew what they intended when they defined the int 
(integer) data type and size.
0
John
12/29/2008 11:32:44 AM
"Rudy Velthuis (TeamB)" wrote:
> Dan Barclay wrote:
>
>> I don't have K&R with me since I'm on the road, but I do recall the
>> wording you quote ("typically the natural size" etc).  That is
>> descriptive, not specification.  Elsewhere in the language definition
>> is the actual specification.  If you can put your hands on that I
>> think you'll find the minimum size specified.
>
> Probably something along the lines of:
>
>  sizeof(short) <= sizeof(int) && sizeof(int) <= sizeof(long)
>
> Note that the actual sizes are implementation-dependent, i.e. decided
> by the writers of the compiler. <g>

As K&R said. "As you can see, each compiler is free to interpret short and 
long as appropriate for it's own hardware. About the only thing you should 
count on is that short is no longer than long."
0
John
12/29/2008 11:41:40 AM
Rudy Velthuis (TeamB) schrieb:
> Robert Dawson wrote:
> 
>> "Rudy Velthuis (TeamB)" wrote
>>> I don't even think that the OS does.
>> Well, it does in the sense that the win64 API specifies call params
>> of a certain size, and documents them as being Integers.
> 
> Most of them are documented as DWORDs, LPARAMs, UINTs, INTPTRs, or
> such, and these can be seen as fixed size items. You'll hardly see
> "int" being used as a parameter to a Windows API function, or as a
> field of a Windows API structure.
> 

Yep, and sometimes MS even misuses UInt by feedding it -1 in an example.
Grr! All due to the lax type checking of C...

Greetings

Markus
0
Markus
12/29/2008 11:45:46 AM
> The compiler writers are no fools.

I am sure that is true.  However, I do not think that the 
intelligence of compiler writers (and programming tools) has 
increased over the years enough to accommodate the additional 
present-day complexity of the compilers' operating environment 
and the users' applications while providing the same attention 
to detail as in the early days. --JohnH
0
John
12/29/2008 11:46:38 AM
Hello,

why do you want to waste memory to store additional 4 bytes which aren't
needed in most cases? You don't want to sell memory modules to us. do
you? ;-)

Greetings

Markus
0
Markus
12/29/2008 11:58:03 AM
John Herbster wrote:

> Markus Humm wrote:
> 
> > starting with D2009 there are Int32 and UInt32 etc. as well...
> 
> Will that extend to Int8, UInt8, Int16, etc. as well?  

from system.pas

{ Useful alias types }
type
  Int8   = ShortInt;
  Int16  = SmallInt;
  Int32  = Integer;
  UInt8  = Byte;
  UInt16 = Word;
  UInt32 = Cardinal;


You really need to get a copy for yourself <g>

-- 
Pieter

"If you're sick and tired of the politics of cynicism and polls 
 and principles, come and join this campaign." -- George W. Bush
0
Pieter
12/29/2008 12:17:32 PM
"Rudy Velthuis (TeamB)" wrote
>
> I am not defending anyone. I am merely wondering why this, which is
> soooo obvious, is such an issue for you.

And I marvel at your lack of intellectual curiousity, and your ability not 
to draw a obvious analogy betweeen the statements "It's entirely obvious; 
that's the way my mother did it" and "It's entirely obvious; that's the way 
the compiler writers did it"

It occurs to me to ask why.

The tale is a common piece of american folklore, incidentally--don't know 
that it has any currency in europe. If you google <cut the ends off the ham> 
you'll get a half dozen different versions.

bobD
0
Robert
12/29/2008 12:27:43 PM
"Markus Humm" wrote
>
> why do you want to waste memory to store additional 4 bytes

I don't believe I've argued that we should

> which aren't
> needed in most cases?

Interesting point--is that a claim about the CPU, the OS, or the external 
world? If the latter, are you arguing that 32bit integers are somehow more 
'fit' for general use than either 16 or 64? That 32bits constitutes a 
'natural' integer size in the real world?

> You don't want to sell memory modules to us. do
> you? ;-)

Nope--no stock there that I know of <g>.

I am interested, however, in the observation that machines being sold on the 
street with 64bit operating systems commonly have 4GB memory limits. So 
going from 32 to 64 bit computng looks a lot like going from a train to a 
plane that's designed to get no more than a meter off the ground. Seems a 
bit odd, doesn't it?

bobD


>
> Greetings
>
> Markus
0
Robert
12/29/2008 12:43:39 PM
"Robert Dawson" wrote:
>
> I am interested, however, in the observation that machines being sold on 
> the street with 64bit operating systems commonly have 4GB memory limits. 
> So going from 32 to 64 bit computng looks a lot like going from a train to 
> a plane that's designed to get no more than a meter off the ground. Seems 
> a bit odd, doesn't it?

AFAIK most machines being sold have an 8GB memory limitation imposed by the 
memory management chipset and most have two dual module memory slots so you 
would need use 4GB memory modules and they are a bit more than twice as 
expensive as 2GB memory modules.
0
John
12/29/2008 12:55:29 PM
Robert Dawson wrote:
> "Rudy Velthuis (TeamB)" wrote
>> I am not defending anyone. I am merely wondering why this, which is
>>  soooo obvious, is such an issue for you.
> 
> And I marvel at your lack of intellectual curiousity, and your
> ability not to draw a obvious analogy betweeen the statements "It's
> entirely obvious; that's the way my mother did it" and "It's entirely
> obvious; that's the way the compiler writers did it"
> 
> It occurs to me to ask why.

Google for ILP64 and LP64. Enough of the discussion between 32bit and
64bit integers under 64bit operating systems used those terms over
the past decade or so to get an idea of why LP64 won out.

Brian
0
Brian
12/29/2008 1:01:05 PM
John Cash wrote:
> "Robert Dawson" wrote:
>> I am interested, however, in the observation that machines being sold on 
>> the street with 64bit operating systems commonly have 4GB memory limits. 
>> So going from 32 to 64 bit computng looks a lot like going from a train to 
>> a plane that's designed to get no more than a meter off the ground. Seems 
>> a bit odd, doesn't it?
> 
> AFAIK most machines being sold have an 8GB memory limitation imposed by the 
> memory management chipset and most have two dual module memory slots so you 
> would need use 4GB memory modules and they are a bit more than twice as 
> expensive as 2GB memory modules.

....and Win32 is limited to 2GB (or 3GB with trick)
hehe
0
Ralf
12/29/2008 2:03:21 PM
Ralf Stocker wrote:

> ...and Win32 is limited to 2GB (or 3GB with trick)

	4GB on Win64 with /3GB switch.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
12/29/2008 2:09:14 PM
"Ralf Stocker" <nospam@nospam.org> wrote in message 
news:60352@forums.codegear.com...
> John Cash wrote:
>> "Robert Dawson" wrote:
>>> I am interested, however, in the observation that machines being sold on
>>> the street with 64bit operating systems commonly have 4GB memory limits.
>>> So going from 32 to 64 bit computng looks a lot like going from a train 
>>> to
>>> a plane that's designed to get no more than a meter off the ground. 
>>> Seems
>>> a bit odd, doesn't it?
>>
>> AFAIK most machines being sold have an 8GB memory limitation imposed by 
>> the
>> memory management chipset and most have two dual module memory slots so 
>> you
>> would need use 4GB memory modules and they are a bit more than twice as
>> expensive as 2GB memory modules.
>
> ...and Win32 is limited to 2GB (or 3GB with trick)
> hehe

Win32 will address 4GB memory and use more with a trick. tee-hee
0
John
12/29/2008 2:19:38 PM
John Cash wrote:
> "Ralf Stocker" <nospam@nospam.org> wrote in message 
> news:60352@forums.codegear.com...
>> John Cash wrote:
>>> "Robert Dawson" wrote:
>>>> I am interested, however, in the observation that machines being sold on
>>>> the street with 64bit operating systems commonly have 4GB memory limits.
>>>> So going from 32 to 64 bit computng looks a lot like going from a train 
>>>> to
>>>> a plane that's designed to get no more than a meter off the ground. 
>>>> Seems
>>>> a bit odd, doesn't it?
>>> AFAIK most machines being sold have an 8GB memory limitation imposed by 
>>> the
>>> memory management chipset and most have two dual module memory slots so 
>>> you
>>> would need use 4GB memory modules and they are a bit more than twice as
>>> expensive as 2GB memory modules.
>> ...and Win32 is limited to 2GB (or 3GB with trick)
>> hehe
> 
> Win32 will address 4GB memory and use more with a trick. tee-hee

Most user don't know tricks. That's the problem...
Win64 + Delphi Win64 would help a lot!
0
Ralf
12/29/2008 2:46:41 PM
"Ralf Stocker" wrote:
> John Cash wrote:
>> 
>> Win32 will address 4GB memory and use more with a trick. tee-hee
> 
> Most user don't know tricks. That's the problem...
> Win64 + Delphi Win64 would help a lot!

Why haven't you taught you users the PAE trick?
0
John
12/29/2008 2:54:40 PM
Pieter,

| You really need to get a copy for yourself <g>

In John's defense, who would think to look in system.pas for such
items?  I sure didn't know that either. <g>

Thanks!

-- 

   Q

12/29/2008 09:08:10

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/29/2008 5:10:30 PM
Robert Dawson schrieb:
> "Markus Humm" wrote
>> why do you want to waste memory to store additional 4 bytes
> 
> I don't believe I've argued that we should

No, but arguing to make 64 bit the default integer results in such a
effect. 64 bit integers should only used for cases where they are
necessary and thus not be the default if, what was stated elsewhere
here, is true: that 32 bit operations are equally fast on 64 bit CPUs as
64 bit operations. Using 64 bit integers for nearly everyting would only
waste memory and needing more memory often slows things down. But I
think you knew that fact already...

Greetings

Markus
0
Markus
12/29/2008 5:14:09 PM
Rudy Velthuis (TeamB) wrote:
> Quentin Correll wrote:
> 
>> Rudy,
>>
>>>  This is not rocket science, is it?
>> Perhaps to those not familiar with hardware machine architecture and
>> assembly coding it may appear as such.  ;-)
> 
> Well, I assume that those who want to discuss this in depth have enough
> knowledge of the matter, otherwise they would not even know what they
> were talking about. <g>
> 
I've never seen a case where lack of knowledge inhibited the exchange of 
mis-information. ;-o

Mike
0
Mike
12/29/2008 5:14:43 PM
Quentin Correll wrote:

> In John's defense, who would think to look in system.pas for such
> items? 

	Search->Find in Files.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
12/29/2008 5:16:39 PM
Rudy,

| |  <setting watch>
| 
| <g>

As "funny" as that seems...
In Sept. 2007 I bought myself and my wife watches that receive the
"atomic clock" radio signal from the US NBS and are supposed to set
themselves to the precise time every night at 03:00.  I had to replace
the batteries in both watches last month.  They no longer receive the
signal and both watches are off both in hours and days.  And WON"T SET
at all! <grumble>  Cheap Chinese cr*p!

(Feel free to move this reply. <g>)

-- 

   Q

12/29/2008 09:10:15

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/29/2008 5:16:54 PM
Robert,

> A distinction without a difference: if Integer isn't changing with register
> size to 64bit, then its status as 'generic' is rather meaningless.
>
> Unless you thnk we'll be seeing 128bit in the foreseeable future ...<g>

well, i think the point is it might, say, be 64-bit in Delphi for the 
Mac. iow "Integer"'s bitness is driven by the platform, not the CPU, and 
Microsoft chose to use 32-but integers for Win64, but that might or 
might not be the case for other 64-bit platforms.

marc
0
marc
12/29/2008 5:21:47 PM
Quentin Correll wrote:

> Pieter,
> 
> | You really need to get a copy for yourself <g>
> 
> In John's defense, who would think to look in system.pas for such
> items?  I sure didn't know that either. <g>

Me neither, I just typed the given *Int32* (by Markus) in the code
editor and clicked on it and ended up in System.pas where the others
happened to be defined as well ;-)

-- 
Pieter

"I invented the term Object-Oriented, and I can tell you I did 
 not have C++ in mind." -- Alan Kay
0
Pieter
12/29/2008 5:32:21 PM
Craig,

| Search->Find in Files.

<chuckle>

-- 

   Q

12/29/2008 09:51:00

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/29/2008 5:52:18 PM
Pieter,

| Me neither, I just typed the given Int32 (by Markus) in the code
| editor and clicked on it and ended up in System.pas where the others
| happened to be defined as well ;-)

Cool!

Thanks again.

-- 

   Q

12/29/2008 09:51:56

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/29/2008 5:53:12 PM
Mike,

| I've never seen a case where lack of knowledge inhibited the exchange
| of mis-information. ;-o

ROFL!

-- 

   Q

12/29/2008 09:53:25

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/29/2008 5:54:35 PM
Robert Dawson wrote:

> "Barry Kelly" wrote
> 
> > FWIW, the decision to use 32-bit integers on Win64 was Microsoft's, not
> > ours. I also think it's the right decision.
> 
> In my own case at least, what's right or wrong is not at issue. I'm just 
> trying to come to some conceptual clarity about what the terms mean. Would 
> the following be correct?
> 
> LongInt: fundamental type fixed at 32bits
> Integer: generic type, size determined by standard 'Integer' definition of 
> OS

These are defined by C ABI of the main C compiler on the underlying
platform, specifically the exact widths used by the OS header files. It
comes down to the pragmatics of interop with the OS. Specifically,
Integer maps to int, Longint maps to long, etc.

> NativeInt: generic type, size determined by data width of hardware logical 
> memory address space--essentially sizeof(pointer)

I'd like to say SizeOf(NativeInt) == SizeOf(Pointer) - cast in stone -
but I hesitate to do so, as I can't foretell the future to know for
certain that no addressing mode yet to be invented will always have an
exact correspondence to an integral type. The strongest thing I expect
to be able to say is that:

var
  p: Pointer;
  i: NativeInt;
begin
  i := NativeInt(p);
  p := Pointer(i);
end;

.... should result in p having the same value that it started out with.

Even then, I can't guarantee that it refers to the same logical object,
as e.g. garbage collection might be in effect, since the cast is unsafe
with respect to a GC memory model.

Oh, and the WinAPI type is called INT_PTR, not INTPTR. Sorry.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/30/2008 7:08:23 AM
marc hoffman wrote:

> Robert,
> 
> > A distinction without a difference: if Integer isn't changing with register
> > size to 64bit, then its status as 'generic' is rather meaningless.
> >
> > Unless you thnk we'll be seeing 128bit in the foreseeable future ...<g>
> 
> well, i think the point is it might, say, be 64-bit in Delphi for the 
> Mac. iow "Integer"'s bitness is driven by the platform, not the CPU, and 
> Microsoft chose to use 32-but integers for Win64, but that might or 
> might not be the case for other 64-bit platforms.

Annoyingly enough, Linux (and most other *nix) x64 has chosen
sizeof(int) == 4, sizeof(long) == sizeof(void*) (i.e. LP64, vs LLP64 for
Win64).

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/30/2008 7:14:13 AM
Giel - <> wrote:

> Oh, that works indeed. But sizeof(system.NativeInt) = 8 !?!

It was undocumented, and it had a bug.

However, the following code still held true (!):

var
  p: Pointer;
  i: NativeInt;
begin
  i := NativeInt(p);
  p := Pointer(i); // p gets same value that it started with
end;

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
12/30/2008 7:17:41 AM
Quentin Correll schrieb:
> Pieter,
> 
> | Me neither, I just typed the given Int32 (by Markus) in the code
> | editor and clicked on it and ended up in System.pas where the others
> | happened to be defined as well ;-)
> 
> Cool!
> 
> Thanks again.
> 

I got them from a recent CG whitepaper where those were explained!

Greetings

Markus
0
Markus
12/30/2008 12:16:35 PM
"Barry Kelly" wrote
>
> Integer maps to int, Longint maps to long, etc.

The demand for conceptual clarity is not a demand for absolute rationality: 
I understand that these things are historically overdetermined. 
Nevertheless, we can be clear about even the most arbitrary conventions.

What your statement immediately implies, together with the general C 
requirement that
  sizeof(short) <= sizeof(int) <= sizeof(long)
is that the Delphi help is certainly in error in giving Integer as a generic 
type, but Shortint and Longint as fundamental (ie unchanging) types. One 
simply cannot map an unchanging type to what is changeable in the underlying 
ecosystem.

> I'd like to say SizeOf(NativeInt) == SizeOf(Pointer) - cast in stone -
> but I hesitate to do so, as I can't foretell the future to know for
> certain that no addressing mode yet to be invented will always have an
> exact correspondence to an integral type.

That does, however, seem to be the direction that MS is going in adding a 
new category of 'generic' types: the Pointer-Precision Integer Types 
(http://msdn.microsoft.com/en-us/library/aa489638.aspx)

This leaves us with now three classes of integral declarations
the generics, understood to float with underlying architecture 
(short/int/long)
the fundamental/fixed types: int16, int32, int64, etc
and pointer-precision types: NativeInt, which would seem to map to INT_PTR

bobD
0
Robert
12/30/2008 1:12:17 PM
Barry Kelly wrote:

> > LongInt: fundamental type fixed at 32bits
> > Integer: generic type, size determined by standard 'Integer'
> > definition of OS
> 
> These are defined by C ABI of the main C compiler on the underlying
> platform, specifically the exact widths used by the OS header files.
> It comes down to the pragmatics of interop with the OS. Specifically,
> Integer maps to int, Longint maps to long, etc.

In C and C++, perhaps. I don't think that Longint should ever change
size.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If the code and the comments disagree, then both are probably
 wrong." -- attributed to Norm Schryer
0
Rudy
12/30/2008 3:13:15 PM
Markus Humm wrote:

> Yep, and sometimes MS even misuses UInt by feedding it -1 in an
> example.  Grr! All due to the lax type checking of C...

  const
    MySpecialValue = UInt(-1);

No problem. <g>



-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Our government has kept us in a perpetual state of fear - kept
 us in a continuous stampede of patriotic fervor - with the cry
 of grave national emergency." -- General Douglas MacArthur
0
Rudy
12/30/2008 3:14:28 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > I am not defending anyone. I am merely wondering why this, which is
> > soooo obvious, is such an issue for you.
> 
> And I marvel at your lack of intellectual curiousity,

What do you know about my intellectual curiosity?

But one can overdo this, and asking questions like "why do you eat your
soup with a spoon?" is not intellectual curiosity, even if you think so.

 and your
> ability not to draw a obvious analogy betweeen the statements "It's
> entirely obvious; that's the way my mother did it"

Well no, the analogy is totally missing, since what the wife and her
mother in the story did was NOT obvious and it did NOT make any sense
(except for granny with her smaller pot), while this is obvious and
does make a lot of sense. And I explained exactly why, which was not
somwthing the wife and mother in law could have done.

Of course language writers use the same ABI as the vendor of the OS.
Anything else would be extremely foolish. This is so obvious that I
don't quite see the need for any "intellectual curiosity".

And the ABI MS chose makes a lot of sense too, since, on Win64, using
Int64 by default is pure overkill, and not one bit faster than Longint.
Just count the situations where you would really need Int64 and then
think again if it makes sense.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The mistakes are all waiting to be made."
 -- chessmaster Savielly Grigorievitch Tartakower (1887-1956) 
    on the game's opening position
0
Rudy
12/30/2008 3:30:07 PM
Robert Dawson wrote:

> > which aren't
> > needed in most cases?
> 
> Interesting point--is that a claim about the CPU, the OS, or the
> external world?

About real life situations. Just think of how often you had the need
for a 64 bit integer. Just count the number of occurrences of Int64 in
all your code and then compare that to the number of occurrences of
Integer.

Then think of the situations where you use Integer, and what the limits
of the values you use are. Then you'll see that most of the time when
you use Integer, your values lie well in the range -32678..32767. IOW,
for most situations, probably even 32 bit are overkill. But they are
faster than 16 bit, so we use them. But 64 bit are not one iota faster
than 32 bit, on x86-64 computers, so why waste 4 bytes per integer?
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Nine out of ten doctors agree that one out of ten doctors is 
 an idiot."
0
Rudy
12/30/2008 3:39:57 PM
John Herbster wrote:

> > The compiler writers are no fools.
> 
> I am sure that is true.  However, I do not think that the 
> intelligence of compiler writers (and programming tools) has 
> increased over the years enough to accommodate the additional 
> present-day complexity of the compilers' operating environment 
> and the users' applications while providing the same attention 
> to detail as in the early days. --JohnH

I think that their intelligence is good enough to grasp these factors.
Earlier compiler writers simply did have simpler preconditions.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A good sermon should be like a woman's skirt: short enough to 
 arouse interest but long enough to cover the essentials." 
 -- Ronald Knox.
0
Rudy
12/30/2008 3:42:18 PM
Quentin Correll wrote:

> Rudy,
> 
> | |  <setting watch>
> >  
> | <g>
> 
> As "funny" as that seems...
> In Sept. 2007 I bought myself and my wife watches that receive the
> "atomic clock" radio signal from the US NBS and are supposed to set
> themselves to the precise time every night at 03:00.  I had to replace
> the batteries in both watches last month.  They no longer receive the
> signal and both watches are off both in hours and days.  And WON"T SET
> at all! <grumble>  Cheap Chinese cr*p!
> 
> (Feel free to move this reply. <g>)

Heheh, most of the clocks in our house (but not my watch) are synced
with the atomic clock in Braunschweig (Brunswick) here in Germany, and
they update every 10 or 15 minutes or so. So changing batteries is no
problem. They are back on track after 10 or 15 minutes.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Love is friendship set on fire." -- Jeremy Taylor
0
Rudy
12/30/2008 3:45:19 PM
Mike Reublin wrote:

> I've never seen a case where lack of knowledge inhibited the exchange
> of mis-information. ;-o

LOL!

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Grove giveth and Gates taketh away."
 -- Bob Metcalfe (inventor of Ethernet) on the trend of hardware
    speedups not being able to keep up with software demands
0
Rudy
12/30/2008 3:45:48 PM
Brian Evans wrote:

> > It occurs to me to ask why.
> 
> Google for ILP64 and LP64. Enough of the discussion between 32bit and
> 64bit integers under 64bit operating systems used those terms over
> the past decade or so to get an idea of why LP64 won out.

Win64 uses LLP64, AFAIK.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A radioactive cat has eighteen half-lives." -- Unknown
0
Rudy
12/30/2008 4:10:17 PM
Rudy Velthuis (TeamB) wrote:

> Barry Kelly wrote:
> 
> > > LongInt: fundamental type fixed at 32bits
> > > Integer: generic type, size determined by standard 'Integer'
> > > definition of OS
> > 
> > These are defined by C ABI of the main C compiler on the underlying
> > platform, specifically the exact widths used by the OS header files.
> > It comes down to the pragmatics of interop with the OS.
> > Specifically, Integer maps to int, Longint maps to long, etc.
> 
> In C and C++, perhaps. I don't think that Longint should ever change
> size.

Never say (n)ever, but for the coming x years I agree with you on this
<g>

-- 
Pieter

"Is your argument that the Creator of the Universe was working 
 under a deadline and His manager forced Him to rush inefficient
 designs into production?" -- John B. Breckenridge in bpot
0
Pieter
12/30/2008 5:10:38 PM
Rudy,

| Heheh, most of the clocks in our house (but not my watch) are synced
| with the atomic clock in Braunschweig (Brunswick) here in Germany, and
| they update every 10 or 15 minutes or so. So changing batteries is no
| problem. They are back on track after 10 or 15 minutes.

Lucky you. <g>

-- 

   Q  <still grumbling>

12/30/2008 09:15:50

XanaNews Version 1.18.1.52  [Everyone's & Q's Mods]
0
Quentin
12/30/2008 5:17:40 PM
"Rudy Velthuis (TeamB)" wrote
>
> Well no, the analogy is totally missing, since what the wife and her
> mother in the story did was NOT obvious and it did NOT make any sense

It was and did to them. Point of view is important.

> (except for granny with her smaller pot), while this is obvious and
> does make a lot of sense. And I explained exactly why, which was not
> somwthing the wife and mother in law could have done.

they certainly could, and did--they explained that that was obviously the 
correct action because that's what their mother (the compiler writers) did. 
It wasn't obvious to them that the explanation they give wasn't particularly 
convincing.

> Anything else would be extremely foolish.

Actually, Windows is fairly ideosyncratic in going with LLP64. Here's a very 
different version of what's 'sensible':
http://www.unix.org/version2/whatsnew/lp64_wp.html

I'm afraid the actual reasons for win64's direction has a lot more to do 
with history than being 'sensible' anyway. See, for example,
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Basically, you can't have 64bit integers while keeping 32bit longs, and long 
is assumed to be 32 bits in too much code to change. So it's not about 
whether 32bits is bit enough for most uses, it's simply the fact that MS 
can't change it without breaking way too much.

bobD
0
Robert
12/31/2008 2:41:54 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > Well no, the analogy is totally missing, since what the wife and her
> > mother in the story did was NOT obvious and it did NOT make any
> > sense
> 
> It was and did to them. 

No, it did not. That was why they reacted so harshly when asked. They
didn't have the faintest why it was done that way.

Sorry, but your analogy is not valid at all.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"I am ready to meet my Maker. Whether my Maker is prepared for 
 the great ordeal of meeting me is another matter." 
 -- Winston Churchill.
0
Rudy
12/31/2008 2:55:35 AM
"Rudy Velthuis (TeamB)" wrote
> Robert Dawson wrote:
>> Interesting point--is that a claim about the CPU, the OS, or the
>> external world?
>
> About real life situations.

Which would seem to indicate you actually agree with me--despite your 
arguments--that saying that 'integer' is a generic type reflecting CPU 
architecture really isn't an adequate statement any more.

What might be true is to say that it proved easier to make a 64bit CPU do 
32Bit operations at full speed than it did to face the implications of 
needing to fix everything else. The CPU isn't really the determining 
consideration any more.

The question I have rattling around, however, is whether, in another decade 
or two, 64bits being 'overkill' is going to sound a lot like no one ever 
needing more than 640K.

Now we just need to agree on the rationale for NativeInt, though (Barry's 
caution noted,) calling it an untyped pointer (an integeral type such that 
sizeof(NativeInt) = sizeof(pointer)) still seems reasonably safe to me.

bobD
0
Robert
12/31/2008 3:12:05 AM
"Rudy Velthuis (TeamB)" wrote
> Brian Evans wrote:
>> the past decade or so to get an idea of why LP64 won out.
>
> Win64 uses LLP64, AFAIK.

*nix world (including Solaris) is LP64. Windows is the oddball.

bobD
0
Robert
12/31/2008 3:14:44 AM
Rudy Velthuis (TeamB) schrieb:
> Markus Humm wrote:
> 
>> Yep, and sometimes MS even misuses UInt by feedding it -1 in an
>> example.  Grr! All due to the lax type checking of C...
> 
>   const
>     MySpecialValue = UInt(-1);
> 
> No problem. <g>
> 

But silly nevertheless, since one could legally feed $FFFFFFFF to this
function to get the very same effect and stay within the UInt
definition! So no real use for passing -1 except to confuse the <whoever>.

Just because it works it's not good! ;-)

Greetings

Markus
0
Markus
12/31/2008 10:36:31 AM
Markus Humm wrote:

> >> Yep, and sometimes MS even misuses UInt by feedding it -1 in an
> >> example.  Grr! All due to the lax type checking of C...
> > 
> >   const
> >     MySpecialValue = UInt(-1);
> > 
> > No problem. <g>
> > 
> 
> But silly nevertheless, since one could legally feed $FFFFFFFF to this
> function to get the very same effect and stay within the UInt
> definition!

Well yes, but just in case UINT had changed from 32 to 64 byte,
$FFFFFFFF would not have sufficed, while UINT(-1) would still be
correct.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Argue for your limitations, and sure enough they're yours."
 -- Richard Bach
0
Rudy
12/31/2008 4:07:49 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > Brian Evans wrote:
> > > the past decade or so to get an idea of why LP64 won out.
> > 
> > Win64 uses LLP64, AFAIK.
> 
> *nix world (including Solaris) is LP64. Windows is the oddball.

*nix also often uses UTF-32 (or UCS-4), which is also pure overkill for
99.9% of all strings. So Windows may be the oddball, but it makes sense.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"I'm not a member of any organized political party, I'm a 
 Democrat!" -- Will Rogers (1879-1935)
0
Rudy
12/31/2008 4:10:22 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > Robert Dawson wrote:
> > > Interesting point--is that a claim about the CPU, the OS, or the
> > > external world?
> > 
> > About real life situations.
> 
> Which would seem to indicate you actually agree with me--despite your
> arguments--that saying that 'integer' is a generic type reflecting
> CPU architecture really isn't an adequate statement any more.

It still reflects CPU architecture. 32 bit registers are the most
optimal for that architecture.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"My advice to you is get married: if you find a good wife you'll 
 be happy; if not, you'll become a philosopher." -- Socrates.
0
Rudy
12/31/2008 4:13:45 PM
>> >> Yep, and sometimes MS even misuses UInt by [feeding] it -1 in an
>> >> example.  Grr! All due to the lax type checking of C...
>> >   const
>> >     MySpecialValue = UInt(-1);

>> But silly nevertheless, since one could legally feed $FFFFFFFF to this
>> function to get the very same effect and stay within the UInt
>> definition!
 
> Well yes, but just in case UINT had changed from 32 to 64 byte,
> $FFFFFFFF would not have sufficed, while UINT(-1) would still be
> correct.

I would probably use
  Const   MySpecialValue = high(UInt);
or 
  Const   MySpecialValue: UInt  = high(UInt);
--JohnH
0
John
12/31/2008 8:23:14 PM
John Herbster wrote:

> >> >> Yep, and sometimes MS even misuses UInt by [feeding] it -1 in an
> >> >> example.  Grr! All due to the lax type checking of C...
> >> >   const
> >> >     MySpecialValue = UInt(-1);
> 
> >> But silly nevertheless, since one could legally feed $FFFFFFFF to
> this >> function to get the very same effect and stay within the UInt
> >> definition!
>  
> > Well yes, but just in case UINT had changed from 32 to 64 byte,
> > $FFFFFFFF would not have sufficed, while UINT(-1) would still be
> > correct.
> 
> I would probably use
>   Const   MySpecialValue = high(UInt);
> or 
>   Const   MySpecialValue: UInt  = high(UInt);
> --JohnH

If I convert such a header, I keep as close to the original as I can,
so I will use UInt(-1).

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"War is not the continuation of politics with different means, 
 it is the greatest mass-crime perpetrated on the community of 
 man." -- Alfred Adler
0
Rudy
12/31/2008 9:40:16 PM
"Rudy Velthuis (TeamB)" wrote
>
> It still reflects CPU architecture. 32 bit registers are the most
> optimal for that architecture.

if in your mind less capable and no faster means optimal, I suppose.

Current intel and AMD offer 32bits--they do not privilege it.

bobD
0
Robert
1/1/2009 1:19:38 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > It still reflects CPU architecture. 32 bit registers are the most
> > optimal for that architecture.
> 
> if in your mind less capable and no faster means optimal, I suppose.

"capable" <> "optimal"

What do you mean with "less capable"?(*) Do you mean "fewer bits"? The
advantage of that is that caches will not fill up so fast, so code
using 32 bit should actually be a little faster. And it has a smaller
memory footprint. Since 32 bit are often already far more than needed,
64 bits are pure nonsense.

Like I said, 32 bit integers are, at the moment, the optimal solution.
They already provide far more "capability" than usually required, and
they have a smaller footprint. They are also a little faster.

(*)I am, as you probably know, a dentist. While most industry drills
are probably far more "capable" than mine, I still prefer my small
dental drills and burs, and so do my patients. IOW, what is "capable"
does not mean it is optimal.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Power is the ability to control things, moral authority is the
 ability to change things" -- Jim Wallis
0
Rudy
1/1/2009 3:19:26 PM
"Rudy Velthuis (TeamB)" wrote

> advantage of that is that caches will not fill up so fast,

Cache size is not really a CPU architecture issue--and in any case on-chip 
caches have been growing much faster than bit width.

> And it has a smaller
> memory footprint.

again, not a CPU issue.

> Since 32 bit are often already far more than needed,
> 64 bits are pure nonsense.

again, not a CPU issue.

> (*)I am, as you probably know, a dentist. While most industry drills
> are probably far more "capable" than mine, I still prefer my small
> dental drills and burs, and so do my patients. IOW, what is "capable"
> does not mean it is optimal.

The problem domain you deal with (things such as dental caries) it highly 
constrained: if you needed to work on an elephants teeth, you might want a 
set of bigger drills.

But that goes right back to my statement that you're in effect making a 
'32bitness fitness' claim about the world--which has nothing whatsoever to 
do with CPU architecture.

I said
"Which would seem to indicate you actually agree with me--despite your
arguments--that saying that 'integer' is a generic type reflecting CPU
architecture really isn't an adequate statement any more.

"What might be true is to say that it proved easier to make a 64bit CPU do
32Bit operations at full speed than it did to face the implications of
needing to fix everything else. The CPU isn't really the determining
consideration any more."

Your only pertinent counter to this statement so far is that current CPUs 
allow 32bit operations without performance penalty--which I never disputed.

bobD


> -- 
> Rudy Velthuis (TeamB)        http://www.teamb.com
>
> "Power is the ability to control things, moral authority is the
> ability to change things" -- Jim Wallis
0
Robert
1/1/2009 3:58:19 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> 
> > advantage of that is that caches will not fill up so fast,
> 
> Cache size is not really a CPU architecture issue

Cache SIZE isn't, but the fact that a CPU uses a cache is. 

If you want to compare performance, all other things should be equal,
right? In the SAME cache on the SAME machine, using Int32 throughout
will cause better performance than using Int64 throughout.

Reason one why Int32 is more optimal.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Modern capitalism is not about free markets, it is about 
 building sufficient mass that the market gravitationally 
 collapses around you."-- Alisdair Meredith
0
Rudy
1/1/2009 4:05:37 PM
Robert Dawson wrote:

> > And it has a smaller
> > memory footprint.
> 
> again, not a CPU issue.
> 
> > Since 32 bit are often already far more than needed,
> > 64 bits are pure nonsense.
> 
> again, not a CPU issue.

Who cares if it is a CPU issue or not? On the same system, the default
use of Int32 is MORE OPTIMAL than that of Int64.

Reasons TWO and THREE why a default to Int32 is more optimal.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"For if he like a madman lived, At least he like a wise one died."
 -- Cervantes.
0
Rudy
1/1/2009 4:12:48 PM
"Rudy Velthuis (TeamB)" wrote
> In the SAME cache on the SAME machine, using Int32 throughout
> will cause better performance than using Int64 throughout.

All things being equal, you'd get better more cache hits dropping back to 8 
or 16 bits.

Its still goes back to a claim that 32bits is all you need--a claim I think 
challengable. Pointers are already beyond 32bits, and business databases are 
routinely going to int64 and even guids for primary ids.

bobD
0
Robert
1/1/2009 5:17:04 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > In the SAME cache on the SAME machine, using Int32 throughout
> > will cause better performance than using Int64 throughout.
> 
> All things being equal, you'd get better more cache hits dropping
> back to 8 or 16 bits.

But these are SLOWER. 32 bits are NOT SLOWER than 64 bits. The OPTIMAL
solution is 32 bits, period.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Rarely is the question asked: Is our children learning?"
 -- George W. Bush
0
Rudy
1/1/2009 6:06:46 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > In the SAME cache on the SAME machine, using Int32 throughout
> > will cause better performance than using Int64 throughout.
> 
> All things being equal, you'd get better more cache hits dropping
> back to 8 or 16 bits.
> 
> Its still goes back to a claim that 32bits is all you need

That's nonsense, of course. Some people even need huge integers with
thousands of bits. But 32 bits are already more than you'll you need in
99.9% of the time (yes, I made that percentage up, but I'm sure it is
pretty close).

So, once again, on an x86-64, MS's choice of using 32 bits integers by
default in Win64 was the optimal choice.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The wit makes fun of other persons; the satirist makes fun of 
 the world; the humorist makes fun of himself." 
 -- James Thurber (1894-1961), 
    in Edward R. Murrow television interview
0
Rudy
1/1/2009 6:11:37 PM
>> | Me neither, I just typed the given Int32 (by Markus) in the code
>> | editor and clicked on it and ended up in System.pas where the others
>> | happened to be defined as well ;-)
>
> I got them from a recent CG whitepaper where those were explained!

<duck and run>
Does the D2009 help have any reference to these type aliases?
</ducks and runs>

cheers,

Chris
0
Chris
1/2/2009 12:14:24 AM
Chris Morgan wrote:

> > > >  Me neither, I just typed the given Int32 (by Markus) in the
> > > > code  editor and clicked on it and ended up in System.pas where
> > > > the others  happened to be defined as well ;-)
> > 
> > I got them from a recent CG whitepaper where those were explained!
> 
> <duck and run>
> Does the D2009 help have any reference to these type aliases?
> </ducks and runs>
> 
> cheers,
> 
> Chris

Use the Source Luke, errr Chris ;-)

-- 
Pieter

"I don't pray because I don't want to bore God." -- Orson Welles.
0
Pieter
1/2/2009 2:14:15 AM
>
> Use the Source Luke, errr Chris ;-)

That shouldn't really be necessary though should it?
The help is meant to, err, help!

cheers,

Chris
0
Chris
1/2/2009 9:39:14 PM
Chris Morgan wrote:

> > 
> > Use the Source Luke, err Chris ;-)
> 
> That shouldn't really be necessary though should it?

Nope.

> The help is meant to, err, help!

Although I do agree, I do poke around in the sources more than I read
the help-files, except for API related stuff.  That gives more an idea
of what is going on and what other stuff is already available.

-- 
Pieter

"Police arrested two kids yesterday, one was drinking battery 
 acid, the other was eating fireworks. They charged one and let 
 the other one off." -- Tommy Cooper
0
Pieter
1/3/2009 10:59:16 PM
>> The help is meant to, err, help!
>
> Although I do agree, I do poke around in the sources more than I read
> the help-files, except for API related stuff.  That gives more an idea
> of what is going on and what other stuff is already available.

Of course the access to the source is indespensible, but it only really
provides implementation details, not background information.

The help should give you the background information
on why the various integer types are defined as they are.
If the help for D2009 had been written properly, many
of the posts in the newsgroups - about moving to unicode
strings, this one about integer sizes and migrating to 64bit,
and posts about generics - would already have been answered.

cheers,

Chris
0
Chris
1/3/2009 11:36:11 PM
Chris Morgan wrote:

> > > The help is meant to, err, help!
> > 
> > Although I do agree, I do poke around in the sources more than I
> > read the help-files, except for API related stuff.  That gives more
> > an idea of what is going on and what other stuff is already
> > available.
> 
> Of course the access to the source is indespensible, but it only
> really provides implementation details, not background information.
> 
> The help should give you the background information
> on why the various integer types are defined as they are.
> If the help for D2009 had been written properly, many
> of the posts in the newsgroups - about moving to unicode
> strings, 

I was about to agree fully ...

> this one about integer sizes and migrating to 64bit,

.... but that would be a little to early to be included in the D2009
help-file. I do hope it will be in the D2010 help-file ;-)

> and posts about generics - would already have been answered.

Indeed.

-- 
Pieter

"Politics is the art of looking for trouble, finding it 
 everywhere, diagnosing it incorrectly, and applying the wrong 
 remedies." -- Groucho Marx
0
Pieter
1/3/2009 11:51:21 PM
>> this one about integer sizes and migrating to 64bit,
>
> ... but that would be a little to early to be included in the D2009
> help-file. I do hope it will be in the D2010 help-file ;-)
>

The NativeInt type is included in D2009 is it not?
So the rationale for including it, and when it should be used
as opposed to when Integer or LongInt should be used,
could easily have been included in the D2009 help.

Codegear's plan for a 64-bit compiler has presumably
been developed over a long period, and has not just
sprung into being following the release of D2009.

Changing the subject slightly;  in the same way
that D7 included (useless) compiler warnings for
unsafe code in preparation for D8.NET, we could
have (had) compiler warnings in D2009 for possibly
unreliable integer/pointer typecasts
etc, which would *really* help our planning for 64-bit.

Please note that I'm talking out of my hat a bit here,
since I don't actually have D2009 yet, still on D2006
here.

cheers,

Chris
0
Chris
1/4/2009 12:23:22 AM
Chris Morgan wrote:

> > > this one about integer sizes and migrating to 64bit,
> > 
> > ... but that would be a little to early to be included in the D2009
> > help-file. I do hope it will be in the D2010 help-file ;-)
> > 
> 
> The NativeInt type is included in D2009 is it not?

Apparently it was already in earlier versions, but it had a wrong value
in, IIRC, D2007.


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Anyone who considers arithmetical methods of producing random 
 digits is, of course, in a state of sin."
 -- John von Neumann (1903-1957)
0
Rudy
1/4/2009 12:25:45 AM
>> The NativeInt type is included in D2009 is it not?
>
> Apparently it was already in earlier versions, but it had a wrong value
> in, IIRC, D2007.

Wow you are quick on the draw tonight Rudy!
A quiet Saturday night for you as well huh?

cheers,

Chris
0
Chris
1/4/2009 12:31:31 AM
Chris Morgan wrote:

> > > The NativeInt type is included in D2009 is it not?
> > 
> > Apparently it was already in earlier versions, but it had a wrong
> > value in, IIRC, D2007.
> 
> Wow you are quick on the draw tonight Rudy!
> A quiet Saturday night for you as well huh?

Everyone is sleeping (hmmm... not sure about my son, but if he is in
his room, with his computer, he is no problem), so I can sit here in
peace without anyone talking to me, or telling me to take out the
garbage or buy some groceries, or some such. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Woman was God's second mistake."
 -- Friedrich Nietzsche (1844-1900)
0
Rudy
1/4/2009 12:38:36 AM
Chris Morgan wrote:

> > > this one about integer sizes and migrating to 64bit,
> > 
> > ... but that would be a little to early to be included in the D2009
> > help-file. I do hope it will be in the D2010 help-file ;-)
> > 
> 
> The NativeInt type is included in D2009 is it not?

Well yes (actually since D7) but consider it to be an
undocumented feature for now.

> So the rationale for including it, and when it should be used
> as opposed to when Integer or LongInt should be used,
> could easily have been included in the D2009 help.

IMO it already is, use LongInt (fundamental type) when size matters
(packed records for instance) and Integer (generic type) for general
purpose and/or best performance on the underlying OS/Platform/CPU...
.... although the distinction could be a bit more emphasized in the
help-file.


> Codegear's plan for a 64-bit compiler has presumably
> been developed over a long period, and has not just
> sprung into being following the release of D2009.

Trying to translate... and failed, it's getting late here ;-)


> Changing the subject slightly;  in the same way
> that D7 included (useless) compiler warnings for
> unsafe code in preparation for D8.NET, we could
> have (had) compiler warnings in D2009 for possibly
> unreliable integer/pointer typecasts
> etc, which would really help our planning for 64-bit.

Did you like these (useless) warnings or did you just turn them off,
like I did ?-)


> Please note that I'm talking out of my hat a bit here,
> since I don't actually have D2009 yet, still on D2006
> here.

I'm sorry, and I mean that, I'm on D2006 too (on my day job ... but not
for long, if all goes as planned).

-- 
Pieter

"Friends may come and go, but enemies accumulate."
 -- Thomas Jones
0
Pieter
1/4/2009 1:40:31 AM
Pieter Zijlstra wrote:
> Well yes (actually since D7) but consider it to be an
> undocumented feature for now.

Quick question: I was reading an old book on developing your own Delphi 
components, and I came across a line where it defined a Handle, as a 32-bit 
integer. I couldn't help but think of this prolific thread. I wondered what they 
would be in 64-bit land. My first thought was that a handle would always have to 
stay 32-bit, because if it didn't, 32-bit apps wouldn't run on a 64-bit OS. And 
pointers need to address more memory, so they necessarily move to 64-bit. But a 
handle could represent an object in memory that occupies many bytes, and thus 
you would always need far fewer handles, and could probably remain 32-bit.

Are my assumptions correct?

Loren sZendre
0
Loren
1/4/2009 1:53:25 AM
Loren Szendre wrote:

> Pieter Zijlstra wrote:
> > Well yes (actually since D7) but consider it to be an
> > undocumented feature for now.
> 
> Quick question: I was reading an old book on developing your own
> Delphi components, and I came across a line where it defined a
> Handle, as a 32-bit integer. I couldn't help but think of this
> prolific thread. I wondered what they would be in 64-bit land. My
> first thought was that a handle would always have to stay 32-bit,
> because if it didn't, 32-bit apps wouldn't run on a 64-bit OS.

Disclaimer: I have no idea what I'm talking about ;-)

But ... so far your assumption doesn't sound that strange.


> And pointers need to address more memory, so they necessarily
> move to 64-bit. 

I'm not sure what that has to do with a Handle.


> But a handle could represent an object in memory that
> occupies many bytes, and thus you would always need far fewer
> handles, and could probably remain 32-bit.

I could imagine that any 32 bit handle still has some data (pointer)
inside, which enables it to access the full 64-bit address range when
needed.


> Are my assumptions correct?

What was your assumption again ?-)


-- 
Pieter

"There are only two tragedies in life: one is not getting what 
 one wants, and the other is getting it."
 -- Oscar Wilde (1854-1900)
0
Pieter
1/4/2009 2:17:23 AM
> What was your assumption again ?-)

That handles in 64-bit land are still 32-bit. (they point to windowed controls, 
of which there are far fewer than memory addresses)

Loren sZendre
0
Loren
1/4/2009 2:27:31 AM
Loren Szendre wrote:

> That handles in 64-bit land are still 32-bit.

Seems unlikely as they are defined as being the same as pointers. 

in WinNT.h

typedef PVOID HANDLE;

Eric Thorniley
0
Eric
1/4/2009 3:05:06 AM
Eric Thorniley wrote:
> Seems unlikely as they are defined as being the same as pointers. 
> 
> in WinNT.h
> 
> typedef PVOID HANDLE;

OK, that is what it is. Then how do 32-bit apps run on 64-bit OS's? Such apps 
have provision for only storing 32-bits for each handle. Does the OS only allow 
32-bit apps to run in the "first 32-bits of memory"?

Loren sZendre
0
Loren
1/4/2009 3:11:32 AM
Loren Szendre wrote:

> Does the OS only allow 32-bit apps to run in the "first 32-bits of
> memory"?
> 
> Loren sZendre

Looks as if handles have only 32 significant bits on Win 64,although
they are 64 bit numbers. See

http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

Eric
0
Eric
1/4/2009 3:32:26 AM
Eric Thorniley wrote:
> Looks as if handles have only 32 significant bits on Win 64,although
> they are 64 bit numbers. See
> 
> http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

That sheds some light on it, for sure!

So does that mean that handles only have 16 significant digits on Win32?

If it did, I could then create a delphi app that had 1000 TEdits on the Main 
Form, and open 70 instances of my app, and cause Windows to run out of handles. 
Just curious.

Loren sZendre
0
Loren
1/4/2009 3:40:24 AM
Loren Szendre wrote:

> Eric Thorniley wrote:
> > Seems unlikely as they are defined as being the same as pointers. 
> > 
> > in WinNT.h
> > 
> > typedef PVOID HANDLE;
> 
> OK, that is what it is. Then how do 32-bit apps run on 64-bit OS's?
> Such apps have provision for only storing 32-bits for each handle.
> Does the OS only allow 32-bit apps to run in the "first 32-bits of
> memory"?
 
Disclaimer: I have no idea what I'm talking about ;-)

Why should 32-significant-bit handles limit us in to not being able to
handle 64 bit addressable memory?

-- 
Pieter

"The man who goes alone can start today; but he who travels with 
 another must wait till that other is ready."
 -- Henry David Thoreau (1817-1862)
0
Pieter
1/4/2009 3:45:09 AM
Loren Szendre wrote:

> Eric Thorniley wrote:
> > Looks as if handles have only 32 significant bits on Win 64,although
> > they are 64 bit numbers. See
> > 
> > http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx
> 
> That sheds some light on it, for sure!
> 
> So does that mean that handles only have 16 significant digits on
> Win32?

No, AFAICS it is limitted to 32 bits on a 32/64 bit applications.

> If it did, I could then create a delphi app that had 1000 TEdits on
> the Main Form, and open 70 instances of my app, and cause Windows to
> run out of handles.  Just curious.

That would surely fail in Delphi 1 ;-)

-- 
Pieter

"Never interrupt your enemy when he is making a mistake."
    - Napoleon Bonaparte (1769-1821)
0
Pieter
1/4/2009 3:50:45 AM
Loren Szendre wrote:

> So does that mean that handles only have 16 significant digits on
> Win32?

I think so (well 16 bits which is what you meant.) From

http://msdn.microsoft.com/en-us/library/ms725486(VS.85).aspx

"There is a theoretical limit of 65,536 user handles per session."

Eric
0
Eric
1/4/2009 3:54:38 AM
Eric Thorniley wrote:
> "There is a theoretical limit of 65,536 user handles per session."

So a session is equivalent to a process?

If so, then one instance of my app, no matter divided across any # of threads, 
could only have 65K UI elements in memory at one time :) Damn! I might need to 
rethink of some of UI's!

Loren sZendre
0
Loren
1/4/2009 4:01:08 AM
Loren Szendre wrote:

 
> So a session is equivalent to a process?

No, a session is a logon session. Most processes run in session 0. Up
to Server 2003,the console login was also in session 0 so with a single
user everything was in session 0. Vista does not allow a user to have
an interactive login in session 0, so you are logged in to session 1 as
a sole user.

As per the MS document,there is a lower quota of handles per process
than the 64K handles per session.

Eric
0
Eric
1/4/2009 4:30:49 AM
Loren Szendre wrote:

> Eric Thorniley wrote:
> > "There is a theoretical limit of 65,536 user handles per session."
> 
> So a session is equivalent to a process?

How did you come to that conclusion?


-- 
Pieter

"A mathematician is a device for turning coffee into theorems."
 -- Paul Erdos
0
Pieter
1/4/2009 4:33:47 AM
Pieter Zijlstra wrote:
> How did you come to that conclusion?

Just responding too quickly :)

I'm in an area that I don't think too often about. Most of my work in Delphi has 
me gleefully ignorant about handles, except for knowing that TGraphicControl 
descendants don't have them and when to choose TSpeedButton over TBitBtn, etc.

So, if we "survived" up till now having 16-bits worth of handles per session 
(with a lower limit based on the reality of memory considerations) -- it looks 
like we'll survive the 64-bit OS era, having only 32-bits worth :)

Loren sZendre
0
Loren
1/4/2009 5:03:09 AM
"Pieter Zijlstra" wrote
>
> IMO it already is, use LongInt (fundamental type) when size matters
> (packed records for instance) and Integer (generic type) for general
> purpose and/or best performance on the underlying OS/Platform/CPU...

That's correct AFAIK to the current helpfile guidance.

The problem is that in C, short, int, and long are _all_ generic types with 
a guaranteed relaionship. And, of course, Delphi Integer maps to int, and 
LongInt maps to long.

So if size matters, Int32 is probably a better choice than LongInt--but 
doesn't show up in the documentation.

Delphi defining LongInt and ShortInt as fundamental types has already 
resulted in an oddity on the other end: ShortInt originally mapped to short, 
but at this point a short is generally 16bits ( = Delphi SmallInt).

bobD
0
Robert
1/4/2009 2:19:19 PM
Loren Szendre wrote:

> Pieter Zijlstra wrote:
> > Well yes (actually since D7) but consider it to be an
> > undocumented feature for now.
> 
> Quick question: I was reading an old book on developing your own
> Delphi components, and I came across a line where it defined a
> Handle, as a 32-bit integer. I couldn't help but think of this
> prolific thread. I wondered what they would be in 64-bit land. My
> first thought was that a handle would always have to stay 32-bit,
> because if it didn't, 32-bit apps wouldn't run on a 64-bit OS. And
> pointers need to address more memory, so they necessarily move to
> 64-bit. But a handle could represent an object in memory that
> occupies many bytes, and thus you would always need far fewer
> handles, and could probably remain 32-bit.
> 
> Are my assumptions correct?

In C++ and C, handles are in fact declared as pointers (but being
opaque types, they can be anything, like pointers to structures or
indices into an array, or hashes, etc.), so I am not so sure.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"I once heard two ladies going on and on about the pains of 
 childbirth and how men don't seem to know what real pain is. I 
 asked if either of them ever got themselves caught in a zipper." 
 -- Emo Philips.
0
Rudy
1/4/2009 5:53:28 PM
Loren Szendre wrote:

> Eric Thorniley wrote:
> > Seems unlikely as they are defined as being the same as pointers. 
> > 
> > in WinNT.h
> > 
> > typedef PVOID HANDLE;
> 
> OK, that is what it is. Then how do 32-bit apps run on 64-bit OS's?

Very simple. They run in the Win32 layer, which will have its own set
of handles. How they translate to 64 bit handles is up to the layer.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"In all large corporations, there is a pervasive fear that 
 someone, somewhere is having fun with a computer on company time. 
 Networks help alleviate that fear." -- John C. Dvorak.
0
Rudy
1/4/2009 5:54:55 PM
Robert Dawson wrote:

> "Pieter Zijlstra" wrote
> > 
> > IMO it already is, use LongInt (fundamental type) when size matters
> > (packed records for instance) and Integer (generic type) for general
> > purpose and/or best performance on the underlying OS/Platform/CPU...
> 
> That's correct AFAIK to the current helpfile guidance.
> 
> The problem is that in C, short, int, and long are all generic types
> with a guaranteed relaionship.

Well, the only guaranteed relationship is that short is not larger than
long. The actual sizes of short, long and normal int depend on the
platform. It is also in the standard that char is 1 byte (but note that
a byte does not necessarily have 8 bits <g>).

But Delphi's Longint has NOTHING to do with C's long. Delphi's Longint
is a fixed size 32 bit integer (even in TP already).

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Incrementing C by 1 is not enough to make a good object-oriented
 language."  -- M. Sakkinen
0
Rudy
1/4/2009 6:00:51 PM
Robert Dawson wrote:

> "Pieter Zijlstra" wrote
> > IMO it already is, use LongInt (fundamental type) when size matters
> > (packed records for instance) and Integer (generic type) for general
> > purpose and/or best performance on the underlying OS/Platform/CPU...
> 
> The problem is that in C, short, int, and long are all generic types
> with a guaranteed relaionship. 

Indeed.

> And, of course, Delphi Integer maps to int, and LongInt maps to long.

For the moment that happens to be the case indeed. But since you say
"of course" you think there must be hard relation between the two, if
so why?
 
> So if size matters, Int32 is probably a better choice than
> LongInt--but doesn't show up in the documentation.

Unless somebody is going to rewrite the help-file I would expect
Delphi's LongInt to stay 32 bit forever.

> Delphi defining LongInt and ShortInt as fundamental types has already
> resulted in an oddity on the other end: ShortInt originally mapped to
> short, but at this point a short is generally 16bits ( = Delphi
> SmallInt).

Hm, not sure, I thought that the C short has "always" been 16 bit so
far (at least in the DOS and Windows 16/32 C-compilers).

-- 
Pieter

"It's strange, isn't it. You stand in the middle of a library 
 and go 'aaaaagghhhh' and everyone just stares at you. But you 
 do the same thing on an aeroplane, and everyone joins in." 
 -- Tommy Cooper
0
Pieter
1/4/2009 8:11:14 PM
Pieter Zijlstra wrote:

> Hm, not sure, I thought that the C short has "always" been 16 bit so
> far (at least in the DOS and Windows 16/32 C-compilers).

There it is. That is because MS chose them that way. That is not a C
thing, though. In C, short and loing are not defined, the standard says
the size depends on the implementation (i.e. of the compiler), and only
states that short must not be larger than long.

So except for the similarity in names, there is nothing that connects
"long int" in C and "Longint" in Delphi. That long int happened to be
32 bit just like Longint is simply common sense. These sizes simply
made most sense.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The years of peak mental activity are undoubtedly between 
the ages of four and eighteen.  At four we know all the 
questions, at eighteen all the answers." -- unknown
0
Rudy
1/4/2009 8:17:57 PM
Rudy Velthuis (TeamB) wrote:

> Pieter Zijlstra wrote:
> 
> > Hm, not sure, I thought that the C short has "always" been 16 bit so
> > far (at least in the DOS and Windows 16/32 C-compilers).
> 
> There it is. That is because MS chose them that way. That is not a C
> thing, though. In C, short and loing are not defined, the standard
> says the size depends on the implementation (i.e. of the compiler),
> and only states that short must not be larger than long.

Indeed but I was re-acting on the following written by Robert:
  "ShortInt originally mapped to short"
and IIRC that was never the case.

> So except for the similarity in names, there is nothing that connects
> "long int" in C and "Longint" in Delphi. That long int happened to be
> 32 bit just like Longint is simply common sense. These sizes simply
> made most sense.

My feelings exactly!

-- 
Pieter

"Nothing is wrong with California that a rise in the ocean level
 wouldn't cure."
 -- Ross MacDonald (1915-1983)
0
Pieter
1/4/2009 8:41:40 PM
Pieter Zijlstra wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > Pieter Zijlstra wrote:
> > 
> > > Hm, not sure, I thought that the C short has "always" been 16 bit
> > > so far (at least in the DOS and Windows 16/32 C-compilers).
> > 
> > There it is. That is because MS chose them that way. That is not a C
> > thing, though. In C, short and loing are not defined, the standard
> > says the size depends on the implementation (i.e. of the compiler),
> > and only states that short must not be larger than long.
> 
> Indeed but I was re-acting on the following written by Robert:
>   "ShortInt originally mapped to short"
> and IIRC that was never the case.

Oh, indeed, it never did. Shortint was always 8 bit (-128..127), while
short used to be 16 bit.


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Reality is that which, when you stop believing in it, doesn't 
go away." -- Philip K. Dick.
0
Rudy
1/4/2009 9:56:59 PM
"Rudy Velthuis (TeamB)" wrote
>
> But Delphi's Longint has NOTHING to do with C's long.

"The size of Integer and Longint are related to the ABI of the underlying
platform, specifically 'int' and 'long' in C."
  -Barry Kelly
  news:<59410@forums.codegear.com>...
this thread

bobD
0
Robert
1/5/2009 2:14:33 AM
"Rudy Velthuis (TeamB)"
>
> Oh, indeed, it never did. Shortint was always 8 bit (-128..127), while
> short used to be 16 bit.

I'll confess that's my assumption, so liable to be wrong. I don't have any 
Turbo C documentation for the period preceeding the definition of ShortInt 
in Delphi/Turbo Pascal.

But if not based on a C short of the period, one wonders what the source 
was. My Turbo Pascal 3 manual doesn't mention ShortInt or SmallInt types.
0
Robert
1/5/2009 3:41:27 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > But Delphi's Longint has NOTHING to do with C's long.
> 
> "The size of Integer and Longint are related to the ABI of the
> underlying platform, specifically 'int' and 'long' in C."

Yeah, I know that one or two at CodeGear have this silly notion that
Longint is not a fixed size integer, but I'm sure we can talk them out
of that. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"I failed to make the chess team because of my height." 
 -- Woody Allen
0
Rudy
1/5/2009 5:55:09 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)"
> > 
> > Oh, indeed, it never did. Shortint was always 8 bit (-128..127),
> > while short used to be 16 bit.
> 
> I'll confess that's my assumption, so liable to be wrong. I don't
> have any Turbo C documentation for the period preceeding the
> definition of ShortInt in Delphi/Turbo Pascal.
> 
> But if not based on a C short of the period, one wonders what the
> source was.

I guess they had to find a name for an 8 bit signed integer, IOW, an
integer smaller than Integer, and someone who had once used C proposed
to prefix it with "short". <g>
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"C++: an octopus made by nailing extra legs onto a dog" 
 -- unknown
0
Rudy
1/5/2009 5:59:28 PM
"Rudy Velthuis (TeamB)" wrote
>
> I guess they had to find a name for an 8 bit signed integer, IOW, an
> integer smaller than Integer, and someone who had once used C proposed
> to prefix it with "short". <g>

Unlikely is shortint and smallint came into the language at the same 
time--surely you'd call a short a shortint and call the distinctive 8-bit 
creature smallint...

I still wonder whether shortint wasn't based on a CP/M Turbo-C short from 
back in the 8-bit days.

bobD
0
Robert
1/6/2009 12:42:42 AM
"Rudy Velthuis (TeamB)" wrote
>
> Yeah, I know that one or two at CodeGear have this silly notion that
> Longint is not a fixed size integer, but I'm sure we can talk them out
> of that. <g>

Unfortunately (according to me), it's been documented as a fundamental type 
that fixing it would be quite painful.

Personally I still think it should be a generic type--fixed types should be 
names what they are: int8, int16, int32 etc. I'm just not sure that at this 
point it CAN be fixed.

bobD
0
Robert
1/6/2009 12:46:49 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > Yeah, I know that one or two at CodeGear have this silly notion that
> > Longint is not a fixed size integer, but I'm sure we can talk them
> > out of that. <g>
> 
> Unfortunately (according to me), it's been documented as a
> fundamental type that fixing it would be quite painful.

What needs to be fixed? 

> Personally I still think it should be a generic type--fixed types
> should be names what they are: int8, int16, int32 etc. 

These were just recently introduced by D2009.

> I'm just not sure that at this point it CAN be fixed.

Again, why do you think this needs to be "fixed" at the moment?

-- 
Pieter

"Some cause happiness wherever they go; others, whenever they go."
 -- Oscar Wilde (1854-1900)
0
Pieter
1/6/2009 1:10:09 AM
"Pieter Zijlstra" wrote
>>
>> Unfortunately (according to me), it's been documented as a
>> fundamental type [for so long] that fixing it would be quite painful.
>
> What needs to be fixed?

That LongInt should be considered a generic type rather than a fundamental 
type, as long is in C.

>> should be named what they are: int8, int16, int32 etc.

> These were just recently introduced by D2009.

Right--the question is why, if the current types are to remain exactly the 
same (ie, types of fixed size).

bobD
0
Robert
1/6/2009 4:19:31 AM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > Yeah, I know that one or two at CodeGear have this silly notion that
> > Longint is not a fixed size integer, but I'm sure we can talk them
> > out of that. <g>
> 
> Unfortunately (according to me), it's been documented as a
> fundamental type that fixing it would be quite painful.
> 
> Personally I still think it should be a generic type

No, it should not. It has always been used as a fundamental type and
changing that now would break a lot of code. I also don't think that
Shortint, Smallint, Word, Longword or Byte should ever change their
sizes.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Save the whales! Collect the whole set!"
0
Rudy
1/6/2009 12:17:37 PM
Robert Dawson wrote:

> "Rudy Velthuis (TeamB)" wrote
> > 
> > I guess they had to find a name for an 8 bit signed integer, IOW, an
> > integer smaller than Integer, and someone who had once used C
> > proposed to prefix it with "short". <g>
> 
> Unlikely is shortint and smallint came into the language at the same
> time

No, they did not. Shortint existed well before Delphi 2. Smallint was
introduced in Delphi 2, when Integer became 32 bit.

This is from BPW7's online help (BPW.HLP):

Integer types

Turbo Pascal provides five predefined Integer types. Each type denotes
a specific subset of the whole numbers, as shown here:

Type		Range				Format

Shortint	-128..127			Signed 8-bit
Integer	-32768..32767		Signed 16-bit
Longint	-2147483648..2147483647	Signed 32-bit
Byte		0..255			Unsigned 8-bit
Word		0..65535			Unsigned 16-bit

All Integer types are ordinal types. 

That list pretty well explains the naming of the integer types of those
days: Shortint (8 bit), Integer (16 bit), Longint (32 bit).

IIRC, TP6 and TP5 also had a Shortint type.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"RAM /abr./: Rarely Adequate Memory." -- From the Jargon File
0
Rudy
1/6/2009 12:25:20 PM
"Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in 
message news:60230@forums.codegear.com...
> Dan Barclay wrote:
>
>> I don't have K&R with me since I'm on the road, but I do 
>> recall the
>> wording you quote ("typically the natural size" etc). 
>> That is
>> descriptive, not specification.  Elsewhere in the 
>> language definition
>> is the actual specification.  If you can put your hands 
>> on that I
>> think you'll find the minimum size specified.
>
> Probably something along the lines of:
>
>  sizeof(short) <= sizeof(int) && sizeof(int) <= 
> sizeof(long)
>
> Note that the actual sizes are implementation-dependent, 
> i.e. decided
> by the writers of the compiler. <g>

There are actually explicit limits in C/C++.

See http://en.wikipedia.org/wiki/Limits.h

Check the "ANSI standard minimum or maximum magnitude value" 
column in the table.

Unfortunately I don't find a copy of the actual C standard 
here.  I do have a reference in the Ellis and Stroustrup C++ 
ref manual.  C++ defaults to the C standards on this so 
their table includes Ansi C standards for the type sizes. 
See 3.2c of that if you like.  The table defines minimum 
sizes for most entries in the limits.h file, and is 
consistent with the wiki above.

Somehow this myth got started the C has no limits on 
variables and it seems to persist.  The compiler writer is 
free to match machine sizes *so long as minimums are met*.

Dan
0
Dan
1/6/2009 6:53:21 PM
Robert Dawson wrote:

> Nevertheless, we can be clear about even the most arbitrary conventions.

I'm not sure that looking for clarity always ends up making things more
clear here. The pragmatics at the time of a platform change dominate,
rather than any "set-in-stone" conventions; and by pragmatics I mean
that backwards compatibility isn't broken without a damn good reason.

Pascal has, since its inception, had an abstraction for solving the
problem of what type to use for portably typing locations containing
integral values that require a certain range. That abstraction is the
subrange type.

For example, if you need something that ranges from 0..100000, you
should define a type that encapsulates that range.

> is that the Delphi help is certainly in error in giving Integer as a generic 
> type, but Shortint and Longint as fundamental (ie unchanging) types. One 
> simply cannot map an unchanging type to what is changeable in the underlying 
> ecosystem.

What size should Shortint be on a machine that doesn't use 8-bit bytes,
or doesn't have 8-bit-multiple addressable words? What would Longint's
range be, and what units would its SizeOf be measured in?

I'm not saying it's a problem that's likely to come up any time soon, or
indeed ever, but saying that things are fundamental and unchanging
forever after without divine foreknowledge is too much.

The pragmatics suggest that Longint and Shortint would never get smaller
in the future. That's a safer long-term bet. But I don't see much
practical value in playing this game.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
1/7/2009 5:29:32 PM
Reply:

Similar Artilces:

Question about Delphi 2009 vs Delphi 7
Hi, I was wondering if any of you can point me to a URLs that show the most important improvements between these versions of Delphi. The objective is convincing the powers-that-pay-the-bills that moving to D2009 (that we'd have to purchase) is a better idea than moving to D7 (for which we have licenses). Fire at will! -- Saluti, Alessandro Federici ------------------------------- "I have been through some terrible things in my life, some of which actually happened." (Mark Twain) Alessandro Federici wrote: > Hi, > I was wondering if any of yo...

Delphi 4 to Delphi 2009
Hello, Thanks to all who answered my previous question. That was a great help. And atlast our client agreed to upgrade our delphi version from 4 to Delphi 2009. *Sigh*. But before that, I need to give the estimation and cost regarding the migration to delphi 2009. Can anyone tell me is there any tool to migrate from delphi 4 to delphi 2009 or just I need to compile our Delphi 4 application in Delphi 2009. I have read from the delphi 2009 feature matrix that Delphi 1 through Delphi 2007 import is possible in delphi 2009. But i am not that sure considering the size of our application. ...

Delphi 5 To Delphi 2009
I upgraded to Delphi 2009 from D5. The install says I can install Delphi and/or C++. Delphi installed OK but I see nothing of C++. What am I missing or does my upgrade not include C++? Thanks It depends on what you bought. If you bought Delphi 2009 only, that's what you get. If you bought Delphi 2009 and C++ Builder 2009 you get both. My guess is you got Delphi 2009 only. The simplest way to verify is look your invoice - it should say I would think. You could also go to members.embarcadero.com, login, then click on my registered products. There will be a textual description of...

Delphi 2009 alongside Delphi 2007
Hi all, I am about to install Delphi 2009 on the same development system as Delphi 2007, before I embark is there anything I should be aware of so as to not break my Delphi 2007 installation and projects ? Thanks JT John Taylor wrote: > Hi all, > > I am about to install Delphi 2009 on the same development system > as Delphi 2007, before I embark is there anything I should be aware > of so as to not break my Delphi 2007 installation and projects ? As long as you install into a separate folder there is no problem with the two versions getting into each other...

Delphi 7 to Delphi 2009 conversion
Hello group, What do I need to do to comile the following code in D2009. Compiler error after the Else E2010: Incompatible Types 'AnsiChar' and 'Char' if isUnicode then SearchHandle := FindFirstFilew( PWideChar( fn ), FindDataW ) else SearchHandle := FindFirstFile( PAnsiChar( Ansistring( fn ) ), FindDataA ); <<<<<compiler error in the above line >>>>>>>>>>> Regards, Bryan > What do I need to do to comile the following code in D2009. > Compiler error after the Else > E2010: Incompati...

Delphi 2007 to Delphi 2009 Conversion
CharArrayPtr = ^CharArray; CharArray = array[0..MaxInt-1] of Char; How to convert to Delphi 2009? Bill Bill Miller wrote: > CharArrayPtr = ^CharArray; > CharArray = array[0..MaxInt-1] of Char; > > How to convert to Delphi 2009? > > Bill it depends heavelly on how it is used fearther down in your project and what you want to convert it to. I you want to simple convert the declarations ignoring UNicode altogether then the only think you have to change is the CharArray declaratin from a Char to an AnsiChar eg CharArrayPtr = ^CharArray; CharArray =...

is there a Delphi 2007
Would be nice to have a bundle of the latest Delphi packages. Gilbert Padilla wrote: > Would be nice to have a bundle of the latest Delphi packages. > I expect Delphi 2007 will only be on sale until the full RAD Studio 2009 edition is published, including Delphi 2009.net. W ...

Upgrading to Delphi 2009 from Delphi 5
I've decided it's time to upgrade to Delphi 2009 Professional from my current Delphi 5 Professional which (according to the FAQ) makes me eligible for the upgrade pricing. However, I'd just like to clarify how this process works. My concern is that my Delphi 5 is not registered on the CodeGear site and this doesn't seem to be possible as far as I can tell. When installing the trial I noticed that Delphi 2009 registers itself with your CodeGear account so does this mean that the previous version must be registered there to verify you own a Professional edition? I plan to o...

Delphi and Delphi Prism licensing question
When I buy Delphi and Delphi Prism, do I get a "named user licence" or a "workstation licence"? Can I install both products on two machines I use with the same licence keys? I have a Mac Pro ("Cyrus") running Vista 64 in VMware and a MacBook ("Blacky") running Vista 32 in Parallels. Can I install Delphi and Delphi Prism on both Cyrus and Blacky since I use both machines (and like to have all dev tools I use installed on both machines at all times)? Andrew Brehm wrote: > When I buy Delphi and Delphi Prism, do I get a "named user licence...

Delphi 2009 Questions
I have been using Delphi 7 for years, but would like to consider 2009, but have third party issues. Perhaps someone has some suggestions for the following: 1. I make heavy use of the GTSizer component to make the forms adjust to whatever screen resolution is being used and to keep all the components and label and grid text proportional for any screen resolution. GTSizer will not support 2009. Does anyone know of another component or method to keeps components proportional? Sure would be nice of Delphi would provide a built in option for this. 2. I have been using the TextControl libra...

ShareMem Delphi 6 --> Delphi 2009
I have just upgraded from Delphi 6 to Delphi 2009. My software uses about 20 files, plus literally dozens more plug-ins. Every project has ShareMem as its first unit and borlndmm.dll is distributed with the software. I am aware that the Borland Memory Manager was replaced to use FastMM quite some time ago. Will I have to rebuild every EXE and DLL in DElphi 2009 that uses ShareMem, or will supplying the new borlndmm.dll be enough? i.e. I would like to just update the main application EXEs and DLLs, but leave the plug-ins alone. Will this work? Thanks, Jason. -- Jason Sweby ...

ShareMem Delphi 6 --> Delphi 2009
I have just upgraded from Delphi 6 to Delphi 2009. My software uses about 20 files, plus literally dozens more plug-ins. Every project has ShareMem as its first unit and borlndmm.dll is distributed with the software. I am aware that the Borland Memory Manager was replaced to use FastMM quite some time ago. Will I have to rebuild every EXE and DLL in DElphi 2009 that uses ShareMem, or will supplying the new borlndmm.dll be enough? i.e. I would like to just update the main application EXEs and DLLs, but leave the plug-ins alone. Will this work? Thanks, Jason. -- Jason Sweby So...

Convert Delphi 7 to Delphi 2009 [Edit]
Hi! Please, I have a code done in Delphi 7... Now I want to convert Delphi 7 to Delphi 2009 but I'm having problems when compile the code. Error message: +[DCC Fatal Error] Far.dpr(9): F2063 Could not compile used unit 'System.pas'+ Please can somebody help me? Source Download (349KB): http://rapidshare.com/files/256191328/FileManager.rar.html Mirror Source Download: http://www.megaupload.com/?d=12GYLPT0 Password: delphi Thank u so much! (sorry for my bad english, it is not my native language) Edited by: loquax loquax on Jul 15, 2009 12:24 PM Sorry, bu...

Code Porting
Hi people, Basically, I am moving an app from Delphi 5 to Delphi 2009 which is all great (yeah right!) and I am having a couple of issues with some thirdparty components that we have the source code for. Being that I wanted to make the task as easy as possible, I was able to download the component in Delphi 2007 format. I have now managed to port that to 2009 so it compiles only with warnings and no errors. So all is good at this moment. Now I am trying to install the component into the IDE by using the install menu option from the project manager. This is where I run into errors. ...

Web resources about - General question on the concept of integer handling in Delphi 2009 - embarcadero.delphi.non-tech

German question - Wikipedia, the free encyclopedia
"Kleindeutschland" redirects here. For the neighborhood in New York City, see Little Germany, Manhattan . 1820 map of Central Europe showing ...

Questions raised over police conduct on union taskforce
Questions have been raised about the appropriateness of a Federal Police officer attached to the union's royal commission speaking at building ...

Media Search of Suspects’ Apartment Raises Questions
“There is something so strange about all of this,” said MSNBC’s Andrea Mitchell , as correspondent Kerry Sanders picked up baby’s toys, sifted ...

Tragedies to question, tragedies to ignore
When a white male shoots people, we ask why, but no explanations are needed when the killers are Muslim.

Question answered
The San Bernardine massacre was caused by workplace stresses combined with climate change.

Some Questions
1.) Yesterday’s shooter was American born, and arguably more American than Ted Cruz. Why isn’t the fact that he was legally able to obtain that ...

The Question People Need to Stop Asking Women
Lately, I'm getting it a lot. The dreaded question. The one that each and every woman in has to hear in her life, probably more than once. I ...

Hillary was asked the blunt question: "You say that all rape victims should be believed, but would you ...
Clearly prepared for that question, she answered: "I would say that everybody should be believed at first until they are disbelieved based on ...

Syed Farook’s Family Doubts FBI’s San Bernardino Account, Questions Sandy Hook Shooting
The family of San Bernardino gunman Syed Farook spoke through their attorney to say they doubted the FBI account regarding their son.

Questions raised on ex-Trump adviser
Trump tapped a man to be a senior business adviser after the man's involvement in a fraud became publicly known, the AP reports.

Resources last updated: 12/6/2015 10:31:25 PM