Linux now an equal Flash player (Linux-Watch) [LWN.net]

Linux now an equal Flash player (Linux-Watch)

Posted Oct 19, 2008 20:24 UTC (Sun) by jengelh (subscriber, #33263)
In reply to: Linux now an equal Flash player (Linux-Watch) by alankila
Parent article: Linux now an equal Flash player (Linux-Watch)

>every pointer

No. There are opcodes that can represent values/pointers in less than full 64 bits. For example, mov rax, 0x7fffffff has two representations:
(1) 48 c7 c0 ff ff ff 7f
(2) 48 b8 ff ff ff 7f 00 00 00 00

And the binary you execute and the heap is often loaded into memory below 0x7fffffff on Linux x86_64. Just check yourself: less /proc/$$/maps. Modules are loaded into higher memory though :-/

(Log in to post comments)

Linux now an equal Flash player (Linux-Watch)

Posted Oct 20, 2008 8:06 UTC (Mon) by jengelh (subscriber, #33263) [Link]

Shared objects and their data area as they are mapped into memory by glibc's libdl.

If the program uses pointers larger than 0x7fffffff, gcc will automatically switch to the next best opcode or opcode group. There is a really ugly case where you move a 64-bit value into a 64-bit (mov qword ptr [rax], 0xdeadbeefdeadbeef), which gets encoded as 2 instructions actually - but: it uses no more than 128 bits for the actual data. So at least you don't lose anything. It's merely that you win a few bits if your values are smaller. (And that's A Good Thing).

There is no flag to generate narrow code hey, "tiny" model and "huge" model were DOS times ;-) GCC will automatically do the best. You might also want to try compiling with -Os, maybe it got more tricks upon its sleeve.

Java.. long topic. There are things it just cannot do efficiently because the language is so restricted. Whereever you would take a pointer/reference in C, whenever you would store an aggregate object on the stack, you have to involve the heap in Java. That is slow. It takes more memory (due to the allocation management). Or if you do not want to do it via the heap, you (can sometimes) replicate the branch in an if/else for example. Both are just plain horrible.

With just a little more brain to spend, you would get the memory benefit, the speed benefit, by using something like C++. I might just even suggest to use GCJ because that just takes less memory at runtime (unfortunately it is not as fast as the SunJVM-JIT on computationally expensive stuff).

Linux now an equal Flash player (Linux-Watch)

Posted Oct 20, 2008 10:06 UTC (Mon) by alankila (subscriber, #47141) [Link]

Okay, so it does it somehow by magic. By your words the automatic decision made by GCC has to be a compile-time one. For runtime, all code generated by GCC will be 64-bit safe; in other words, doing a malloc() say always returns a 64-bit value and there is no way this will be optimized at runtime?

Linux now an equal Flash player (Linux-Watch)

Posted Oct 20, 2008 15:41 UTC (Mon) by jengelh (subscriber, #33263) [Link]

By my words, GCC internally could have something like:

if ((signed long)operand <= 0x7fffffff) spewout(short opcode version, operand); else /* default */ spewout(long opcode version, operand);

With no option to tune it. Why would you even use the slower one when you can avoid it? It's not going to change anything... unless there is a bug in the CPU that causes the short opcode to go haywire.

Yes, malloc always returns a 64-bit quantity, and it does so in a register, which makes accesses cheap with small values: int *x = malloc(sizeof(int)); *x = 5; equates to mov dword ptr [rax], 5 which is the c7 00 code with a 32-bit operand for the "5".

Linux now an equal Flash player (Linux-Watch)

Posted Oct 20, 2008 21:24 UTC (Mon) by Ed_L. (guest, #24287) [Link]

Please define "narrow code" and give a local example :)

My current project targets CentOS/Fedora i386 and x86_64. Operationally, all I need do is specify "gcc -m32" when compiling and linking, and the resulting executable "just works."

Subject to the usual constraints on time and coding intelligence, of course...

Linux now an equal Flash player (Linux-Watch)

Posted Oct 20, 2008 20:20 UTC (Mon) by jengelh (subscriber, #33263) [Link]

see http://www.x86-64.org/documentation/abi.pdf section 3.5.1.