467,075 Members | 988 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,075 developers. It's quick & easy.

Long long int

Hi to all!

I wonder how gcc treat 64bit integer type(long long int) internally in 32bit
machine.

If possible, please tell me the related webpage.

Thank you.
Nov 14 '05 #1
  • viewed: 14385
Share:
8 Replies
"Keoncheol Shin" <kc****@vlsisyn.kaist.ac.kr> wrote in message
news:c0**********@news.kreonet.re.kr...
Hi to all!

I wonder how gcc treat 64bit integer type(long long int) internally in 32bit machine.

If possible, please tell me the related webpage.

Thank you.

I would suspect it is treated as 32bits long were being treated in a 16bit
application: two words = 1 dword

For your case it is two longs to form one 64bits long

--
Elias
Nov 14 '05 #2

"Keoncheol Shin" <kc****@vlsisyn.kaist.ac.kr> wrote in message
I wonder how gcc treat 64bit integer type(long long int) internally in
32bit machine.

Why not do some experiments? Try copying a long long int to an array of
unsigned chars, and examine the layout by printing them in hex format?
Nov 14 '05 #3
Keoncheol Shin wrote:
I wonder how gcc treat 64bit integer type(long long int) internally in 32bit
machine.

The following comments apply to gcc 3.3.1, but the same or similar
structures likely exist in the latest version (3.3.3) as well.

You can see for yourself how gcc handles the "long long" type by
examining two files from the source distribution: gcc/libgcc2.h and
gcc/longlong.h.

The first file defines the following struct and union:

#if LIBGCC2_WORDS_BIG_ENDIAN
struct DWstruct {Wtype high, low;};
#else
struct DWstruct {Wtype low, high;};
#endif

typedef union
{
struct DWstruct s;
DWtype ll;
} DWunion;
The second file contains a flurry of assembler macros that define the
primitive "long long" operations for different processor types. The
"DWunion" type is employed to hold "long long" values for both 32-bit
and 64-bit processors.

As you can see (and as you might have well guessed), "long long" values
are manipulated as structs on 32-bit machines, with the "high" and "low"
members storing the upper and lower 32-bits, respectively, of the 64-bit
value.

NB: this description presents an over-simplified picture of relevant
header files for the purpose of providing a brief explanation. To
obtain of fuller and more precise understanding of what's going on with
gcc's handling of the "long long" type, a much more extensive review of
the source code would be required. In other words, things are not
always quite as simple as they look <g>

Mark

Nov 14 '05 #4
Keoncheol Shin wrote:
Hi to all!

I wonder how gcc treat 64bit integer type(long long int) internally in 32bit
machine.
Well, one of the best ways to see how gcc does /anything/ related to the
details of code generation is to give it the -S option to make it
generate assembly instead of object code. (Assuming you're on an Intel
machine: Note that the default assembly syntax is AT&T, which gas likes
but most humans don't. ;) Give it the -masm=intel option to cure it of
this behavior.)

Also, gcc is a compiler, not a human. It will generate odd and obviously
non-optimal code unless you hand it options like -O3 and
-march=[/something/], where /something/ is what gcc calls your hardware.
(Even then, it's not quite right.) Modern Intel chips are called i686,
but I think the --version option will cause gcc to print its idea of
your hardware.

If possible, please tell me the related webpage.
I like using showasm, a Perl program that takes a C source file and
generates an output file that contains the assembly annotated with the C
source lines that the compiler used to generate it. It's colored with
ANSI escapes, but less will handle it fine if you give less the -R option.

showasm seems to live here:

http://www.ibiblio.org/pub/Linux/dev...asm-1.0.tar.gz

Thank you.

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.
Nov 14 '05 #5
Keoncheol Shin wrote:
I wonder how gcc treat 64bit integer type(long long int) internally in 32bit
machine.


When dealing with 64 bit numbers on a 32 bit CPU you need to sort of
emulate the number processing using TWO 32-bit registers or memory
addresses. all the calculations are done in terms of 32-bits of course.

EXAMPLE:

long.c (Compiled to assembly with gcc -S long.c)

main() {
long long n;
n = 33;
n += 15;
}

long.S

.file "long.c"
.def ___main; .scl 2; .type 32; .endef
.text
..globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
andl $-16, %esp
movl $0, %eax
movl %eax, -12(%ebp)
movl -12(%ebp), %eax
call __alloca
call ___main
movl $0, -8(%ebp)
movl $0, -4(%ebp)
leal -8(%ebp), %eax
addl $15, (%eax)
adcl $0, 4(%eax)
leave
ret

Well I have absolutely no idea what this odd-ball assembly code is doing
so let's look at how a "real" compiler does it.

// unoptimized assembly
main() {
__int64 n;
n = 33;
n += 15;
}

assembly (important parts)

; 2 : __int64 n;
; 3 : n = 33;

mov DWORD PTR _n$[ebp], 33 ; 00000021H
mov DWORD PTR _n$[ebp+4], 0

; 4 : n += 15;

mov eax, DWORD PTR _n$[ebp]
add eax, 15 ; 0000000fH
mov ecx, DWORD PTR _n$[ebp+4]
adc ecx, 0
mov DWORD PTR _n$[ebp], eax
mov DWORD PTR _n$[ebp+4], ecx
Nov 14 '05 #6

"RagnarDanneskjöld" <no*****@hotmail.com> wrote in message
news:ER**********************@news4.srv.hcvlny.cv. net...
Well I have absolutely no idea what this odd-ball assembly code is doing
so let's look at how a "real" compiler does it.


You put that code in main where gcc imposes some limitations try

long long test(long long n) {
return n + 15;
}

Which with -O3 on my cygwin box produces

_test:
movl 4(%esp), %eax
movl 8(%esp), %edx
addl $15, %eax
adcl $0, %edx
ret

Which is not only straightforward but also the most optimal code you can
really write for this function on the x86

Tom
Nov 14 '05 #7
Tom St Denis wrote:
"RagnarDanneskjöld" <no*****@hotmail.com> wrote in message
news:ER**********************@news4.srv.hcvlny.cv. net...
Well I have absolutely no idea what this odd-ball assembly code is doing
so let's look at how a "real" compiler does it.

You put that code in main where gcc imposes some limitations try


Damn why didn't I think to generate with a non-main function.

When I said I had no idea what the heck it was doing: i was referring
more to the syntax of GAS or AT&T or whatever assembly. It's zany.
Nov 14 '05 #8
RagnarDanneskjöld wrote:
Tom St Denis wrote:
"RagnarDanneskjöld" <no*****@hotmail.com> wrote in message
news:ER**********************@news4.srv.hcvlny.cv. net...
Well I have absolutely no idea what this odd-ball assembly code is doing
so let's look at how a "real" compiler does it.


You put that code in main where gcc imposes some limitations try


Damn why didn't I think to generate with a non-main function.

When I said I had no idea what the heck it was doing: i was referring
more to the syntax of GAS or AT&T or whatever assembly. It's zany.


It's ugly as hell, and it's called AT&T. Try using the -masm=intel
argument. That won't make it as clean as, say, nasm's assembly, but it
will make it readable to someone coming from an Intel background.

AT&T's assembly is supposedly ugly to be usable as-is on multiple
architectures. Supposedly, you can use AT&T syntax as a template for a
very generic (non-processor-specific) assembly language, filling in the
opcodes and their exact arguments as the compiler generates them.

Of course, that doesn't wash with me. First off, I doubt the benefits of
trying to shoehorn Intel assembly into something that worked for VAX
assembly, or PowerPC assembly into something that worked for System/360
assembly. Code reuse is good, but that is simple absurdity.

Secondly, trained monkeys could have come up with a better template.
Memory references are particularly FUBARed: What does -3(%eax,%edx,4)
mean? Looking it up, I find it means [eax+edx*4-3]. I chose a rather
absurd example, but it isn't that odd to use rather complex addressing
schemes in a chip as register-starved as an x86 clone. And Intel's
algebraic notation is clearly a win over AT&T's What-The-Fuck notation.

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.
Nov 14 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Tim Clacy | last post: by
7 posts views Thread by William Payne | last post: by
5 posts views Thread by Mark Shelor | last post: by
29 posts views Thread by Richard A. Huebner | last post: by
21 posts views Thread by Charles Sullivan | last post: by
12 posts views Thread by Ahmad Jalil Qarshi | last post: by
2 posts views Thread by PengYu.UT@gmail.com | last post: by
10 posts views Thread by ratcharit@gmail.com | last post: by
15 posts views Thread by Oliver Graeser | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.