From: "Paul Edwards" <mutazilah@gmail.com>
To: "GCC Development" <gcc@gcc.gnu.org>
Subject: Re: extended segments on 80386
Date: Tue, 16 Mar 2021 03:08:04 +1100 [thread overview]
Message-ID: <C2D11745F7994DE7B0B61A76BA0AA96F@DESKTOP0OKG1VA> (raw)
Actually, what I want is a processor with ECS,
EDS and EES, as new registers, and for GCC
to target that, supporting near, far and huge
code pointers and data pointers.
BFN. Paul.
-----Original Message-----
From: Paul Edwards
Sent: Tuesday, March 16, 2021 12:55 AM
To: GCC Development
Subject: extended segments on 80386
Would it be possible for GCC to generate code
that reserves ESI and EDI as "extended segment"
registers to hold a source and destination
"extended segment" of any operation.
This will be the upper 32-bits of a 64-bit address.
When run on a normal 80386, such code will work
fine, and ESI and EDI will always be 0, so that source
and destination are always in the first 4 GiB.
When run on segmentation-aware hardware, the
API to obtain memory, e.g. INT 21H AH=48H (or
something much better, preferably), cx will be
set to 1 to indicate that a "far pointer" is being
requested, and if such memory is available,
EDI will be set to the segment, ie EDI = 2 will
mean the 8 GiB location. The 32-bit offset will
be returned via a normal register, e.g. EAX.
The application will set EDI to 0 before calling
the INT 21H.
Only segment-aware applications will set cx to 1
in the INT 21H request.
The exact same executable will thus work fine, within
the 4 GiB address space, just doing unnecessary
stores and loads of ESI and EDI (always 0), but on
segment-aware hardware, that exact same application
will have access to 16 EiB of memory, although with
size_t restricted to 4 GiB (although you could break
the size_t restriction by using a huge pointer instead
of a far pointer).
If ESI and EDI are not the most appropriate registers,
something else could be chosen.
Will that work?
Thanks. Paul.
next reply other threads:[~2021-03-15 16:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 16:08 Paul Edwards [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-11-24 14:05 i370 port - 3.4.6 to 4.4 upgrade attempt Ulrich Weigand
2009-11-28 15:14 ` i370 port - music/sp - possible generic gcc problem Paul Edwards
2009-11-28 16:03 ` Richard Guenther
2021-03-14 5:55 ` negative indexes Paul Edwards
2021-03-14 8:05 ` Richard Biener
2021-03-14 8:12 ` Paul Edwards
2021-03-14 13:37 ` Richard Biener
[not found] ` <755065BE2A0B4B508DD3A262B2A83801@DESKTOP0OKG1VA>
2021-03-15 9:22 ` Richard Biener
2021-03-15 13:55 ` extended segments on 80386 Paul Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C2D11745F7994DE7B0B61A76BA0AA96F@DESKTOP0OKG1VA \
--to=mutazilah@gmail.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).