From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id A1461385701E for ; Mon, 15 Mar 2021 13:55:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A1461385701E Received: by mail-pf1-x430.google.com with SMTP id t85so6605699pfc.13 for ; Mon, 15 Mar 2021 06:55:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=iWtyG9pqiYkKoMzkjzYOtJwD3OWX9IcnI1v5zdsDyKM=; b=Fa3mH3Rc4RVskmrur3mccXSIZjd2dcUY6eHXBEhRfwFIcVaTciX6abu09fG0+vEGH8 m1K0l+FhxyU5saOPy653MEG/55EMabmTGSARcHBZun5PEwJcCsu4JViV/O22UN1dMqIJ 10d/TeUvD0DH1RPCLa7X8eQ7svBBJC6UMRRz63rtmvjNkIAgwpdrbE97CoH09RV8NJ4a 98IHmpgmY/braE8yTgamRiQUUQ6Ureqehh6shcuxmy2pIgaliAMpuCY/e3tNmUAgCK4n MNutLSf/4hCiJmZZ2WuAL5mwE/AuRDVRcHAg7HSjCgYlVEpaRv8cZqkCgpdmidFGirIv qZQA== X-Gm-Message-State: AOAM531+MeATarrrF2K4F3TlYdPkkaDFcFJKfT2csvnYlGjTtdjn8O8B gt8C+YsjpAm/Kw9+abNJWsCuFd8HMLw= X-Google-Smtp-Source: ABdhPJz24hbYVkFl2iOeBJQuhTJAQWlgNw58mKwDFzwDdvrAjrpwEu7DW2a8sheyhlHLvfcI9AzDZQ== X-Received: by 2002:a05:6a00:1596:b029:200:c2c9:95e7 with SMTP id u22-20020a056a001596b0290200c2c995e7mr17463322pfk.73.1615816511274; Mon, 15 Mar 2021 06:55:11 -0700 (PDT) Received: from DESKTOP0OKG1VA ([202.169.113.201]) by smtp.gmail.com with ESMTPSA id 68sm13853410pfd.75.2021.03.15.06.55.09 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 06:55:10 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "GCC Development" References: <200911241405.nAOE5Jsd022678@d12av02.megacenter.de.ibm.com> <7B52F224E6EE465EB95237D5A0D9A15F@Paullaptop> <84fc9c000911280802j3a0be6b1p1241d81d91f0672e@mail.gmail.com> <7926CAF0-69E7-415D-B635-B7C004EC838A@gmail.com> <755065BE2A0B4B508DD3A262B2A83801@DESKTOP0OKG1VA> In-Reply-To: Subject: extended segments on 80386 Date: Tue, 16 Mar 2021 00:55:05 +1100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, STOX_REPLY_TYPE, STOX_REPLY_TYPE_WITHOUT_QUOTES, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 13:55:13 -0000 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.