Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Oct 2012 20:39:26 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Peter Wemm <peter@wemm.org>
Cc:        Garrett Cooper <yanegomi@gmail.com>, Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org, Dag-Erling Sm??rgrav <des@des.no>, Dimitry Andric <dimitry@andric.com>
Subject:   Re: x86 boot code build
Message-ID:  <20121006173926.GT35915@deviant.kiev.zoral.com.ua>
In-Reply-To: <CAGE5yCp8OWD1Hp%2BYzZBOE-FBtj2WESDKtvVh-VkgH32SMQYaUA@mail.gmail.com>
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> <CAGE5yCp8OWD1Hp%2BYzZBOE-FBtj2WESDKtvVh-VkgH32SMQYaUA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--ubEh+iSFTuEFLNSo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 06, 2012 at 12:28:37AM -0700, Peter Wemm wrote:
> 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):
>=20
> 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).
>=20
> Short version to explain the concept:
>=20
> 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...]
>=20
> 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
>=20
> 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 is still true. We always set %cs, %ss, %ds and %es for the signal
handlers, as well as save the full 64bit register file.

The recent linuxish x32 ABI might be relevant for what you tried to do.
If only they did not mandated bastardized kernel ABI.

--ubEh+iSFTuEFLNSo
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAlBwbM4ACgkQC3+MBN1Mb4hpKgCgre87/SRosswkltWnRFKVU2/z
3bEAoNB+j9b8M9B3E4yS2QZfcPIFIeIU
=8sW5
-----END PGP SIGNATURE-----

--ubEh+iSFTuEFLNSo--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121006173926.GT35915>