Integers vs. Long Integers Was: RE: [AccessD] Global Variable

Stuart,

If there is a conversion at all, it is an instruction that loads 16 bits
into a register instead of an instruction that loads 8 bits or 32 bits.
There is no "operation" that does the conversion, there is simply a register
load, with a register specified, and width specified.  I cannot say with
dead certainly but I would bet good money that the upper 16 bits of a word
can be loaded into either the upper or lower 16 bits of a register using
some variation of the register load. Likewise with the Lower 16 bits of a
memory word.  Thus an array of 16 bit numbers could be packed two variables
per word and not impact performance in any way.  Just a different variation
of the same register load instruction.  In fact, as I mentioned earlier,
since the array could pack the 16 bit integers 2 per word, loading the data
from memory into data cache would be twice as fast.

I will tell you that back in the early 80s I knew the actual instruction set
of the 808x processor, including what the registers looked like, how the
instructions packed into memory etc.  I know how they loaded, I know how the
instructions were broken down into micro-code and the individual pieces of
the instruction sent to the instruction execution units and used to gate
chunks of memory into registers etc., other pieces used to decode the
"instruction" (load, add, shift etc.).

In 1986 I wrote code in assembler for the 68xxx series of processors on
small controllers used in dedicated graphics cards, for test purposes.

I stopped learning the processors to that level at the 80386 so I will
freely admit that I don't have an intimate knowledge of 32 bit instructions,
however I have a very good understanding of machine instructions in general
and the early 808x instructions specifically.  I happen to know that ALL of
those early instructions still exist, with additional instructions added.

In the late 80s I took assembler (8086), I took ONE course in compiler
writing, studying how the instruction is decoded and how the pieces of the
high level instructions (English level tokens) are interpreted and used to
call functions in libraries.  I am certainly not an expert in any of that
but I have at least LOOKED at it.  

NONE of my experience says it takes "3 steps to do with an integer what it
takes 1 step to do with a long".  About the only thing that I would say is
correct is "An integer is a 16 bit variable".

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, May 18, 2005 5:51 PM
To: Access Developers discussion and problem solving
Subject: RE: Integers vs. Long Integers Was: RE: [AccessD] Global Variable


Yes it is.

On 18 May 2005 at 13:30, John W. Colby wrote:

> Not true
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> Contribute your unused CPU cycles to a good cause: 
> http://folding.stanford.edu/
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of 
> DWUTKA at marlow.com
> Sent: Wednesday, May 18, 2005 1:17 PM
> To: accessd at databaseadvisors.com
> Subject: Integers vs. Long Integers Was: RE: [AccessD] Global Variable
> 
> 
> An integer is a 16 bit variable.  Which means, on a 32 bit system 
> (which includes almost anything running Windows), for the processor to 
> use that 16 bit variable, it first converts it into a 32 bit variable.  
> Then it does what it needs to do, then converts it back to a 16 bit 
> variable.
> 
> A long integer is a 32 bit variable.  So it doesn't need to be 
> converted. That means, for every 'transaction' between an integer and 
> a long integer, the integer is going to take longer (3 steps instead 
> of 1)
> 
> Drew