Date: Sat, 6 Oct 2012 00:28:37 -0700 From: Peter Wemm <peter@wemm.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Garrett Cooper <yanegomi@gmail.com>, Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, Dag-Erling Sm??rgrav <des@des.no>, Dimitry Andric <dimitry@andric.com> Subject: Re: x86 boot code build Message-ID: <CAGE5yCp8OWD1Hp%2BYzZBOE-FBtj2WESDKtvVh-VkgH32SMQYaUA@mail.gmail.com> In-Reply-To: <20121006072636.V978@besplex.bde.org> References: <506C385C.3020400@FreeBSD.org> <86a9w1kq94.fsf@ds4.des.no> <20121005133616.GP35915@deviant.kiev.zoral.com.ua> <201210051141.16147.jhb@freebsd.org> <20121006072636.V978@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 5, 2012 at 3:44 PM, Bruce Evans <brde@optusnet.com.au> wrote:
[..]
> Here are results of a current run of old test code: on core2
> (ref10-i386): results only for a data size of 4K (for much smaller
> sizes, simple methods are best, and for much larger sizes, all
> reasonable methods are limited by the speed of main memory and cache
> overheads, and all reasonable methods have the same speed, except ones
> using movnt* are faster since they bypass the caches):
A while ago I experimented with switching 32 bit binaries into 64 bit
mode while running under a 64 bit OS for things like data copies. The
differences between 32 and 64 bit used to be substantial for the
dumber data copy methods. And of course the overheads of getting into
and out of 64 bit mode at the time was prohibitive on an Intel
processor (compared to an AMD).
Short version to explain the concept:
bcopy64:
pushl %ebx
pushl %esi
pushl %edi
call base
base:
popl %esi
movl %esi,%edx
addl $to64-base,%edx
pushl $43 /* $GSEL(GUCODE_SEL, SEL_UPL) */
pushl %edx
lretl
.code64
to64:
movq %rsi,%r9
addq $to32-base,%r9
movq 16(%rsp),%rsi /* src */
movq 24(%rsp),%rdi /* dst */
movq 32(%rsp),%rdx /* len */
[... 64 bit bcopy trimmed...]
2:
/* Jump back to 32 bit code segment */
pushq $27 /* GSEL(GUCODE32_UPL, SEL_UPL) */
pushq %r9
lretq
.code32
.p2align 4
to32:
popl %edi
popl %esi
popl %ebx
ret
Of course, this requires regular i386 code running on an amd64 kernel.
At the time it was quite safe because signal delivery would reset %cs
to deliver signals in 32 bit mode and all 64 bits of all registers
were context switched, even for a 32 bit application.
This was part of a larger skunkworks project I did at work called
"EMM64". (A reference to the old dos EMM386).
It was a set of >4GB extensions and management code for a regular 32
bit app. One of the things we used it for was to mmap a 16GB file
above the 4GB mark and use some hand-rolled hash search code. This
allowed us to use some very large hashed key/value stores (before the
days of things like memcached).
Highlights:
mmap64() etc from a 32 bit process.. to put data above 4GB.
call64(): quick and easy trampoline to minimize assembler code.
dlopen64(), dlsym64(), dlcall64() etc: basically allowed you to
compile severely limited 64 bit .so file and (relatively) easily call
it from an otherwise unmodified 32 bit application.
The use case was to sneak some memory/performace critical patches into
certain 32 bit apps that couldn't/wouldn't be recompiled at work.
Allocating space above the 4GB mark was entirely different than simply
running a small chunk of 64 bit code in 4GB of address space. I had a
kernel module that "patched" a few things in the VM and elf32
wrappers. If it crashed.. well.. elf32 core files didn't express 64
bit mappings too well.
Yeah, it was quite a hack.. by all definitions of the term.
In any case, I'd be curious to know if people could hand tune a hybrid
set of 32+64 data manipulation code to outperform pure i386. It was
clear at the time that badly written hybrid code outperformed badly
written 32 bit code.
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGE5yCp8OWD1Hp%2BYzZBOE-FBtj2WESDKtvVh-VkgH32SMQYaUA>