[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Best Keeps Getting Bigger



Mark Allums put forth on 12/30/2009 12:04 PM:
> I've only done custom kernels on 32bit x86 headless server
>>> platforms, so maybe mine would double in size if I were doing X86-84
>>> kernels due to 8 byte instruction words vs 4 byte words,
> 
> I expect that this is merely terminology, but I don't think that 64-bit
> x86_64/amd64 architecture exactly has eight byte instruction words;
> rather it has 64/128-bit registers.  What mainly changed is the addition
> of many more general purpose registers, and the support for 64-addresses
> (i.e. pointers.)
> 
> You are correct that virtually all 64-bit executable text binaries are
> much larger as a result.

My x86-64 Architectural Programmers Manuals are packed away somewhere so I'll
have to wing it here only stating what I know to be factual.

1.  The original eight 32 bit x86 GPRs were increased in width to 64 bits
2.  Eight additional 64 bit GPRs were added for a total of 16 GPRs
3.  In 64 bit long mode, all registers are available
4.  In 32 bit mode, only the first eight are available
5.  In 32 bit mode, only the first 4 bytes of each register are available

New 64 bit mode instructions were created in essence duplicating most/all of the
previous 32 bit x86 instructions.  I'm unsure of the actual instruction encoding
so I don't know the bit length of each/any/all the 64 bit instructions.  I do
know that all of them are a few bits larger than the 32 bit cousins and some
many bits larger.  I was being simplistic in my previous post for brevity.  The
instruction word bit/byte length isn't doubled across the board, but it is
always larger on average, so 64 bit code is always going to have a larger
footprint, as you state, but it won't be twice the size in most cases.  Wild ass
guess, I'd say it's probably 30-50% larger on average for user space code and
slightly greater for kernel code since it deals so heavily with programming the
hardware and managing memory.

--
Stan


Reply to: