public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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.

             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).