From: muta...@gmail.com
First of all, I'm back on - I realized that it will be a
non-optimizing compiler to start with, so I don't
think there will be negative indexes, there will
instead be an addition.
Oh. I just realized that the addition would require
a wrap too, so I'm back off, unless every addition
does a test for a negative number and does a
subtraction or manual wrap or whatever.
I guess that's the price to pay for the OS (EFI) not
mapping the 4-8 GiB region as required.
On Saturday, March 18, 2023 at 9:44:08 PM UTC+8, Dan Cross wrote:
> In article ,
> muta...@gmail.com wrote:
> >I thought that it was not possible to run 80386 software on an x64 in lm64
because they took away push eax etc so you only have push rax
> >
> >But I just realized that you can manipulate the stack manually. Ie mov eax
to offset 4 from esp etc.
> >
> >And sub esp, 4
> >
> >I don't mind writing a new compiler and I don't mind recompiling everything.
> I wouldn't do that if I were you.
> >So
> >
> >Is it possible to write 80386 code that runs on lm64 without issue?
> Yes. That was one of the important design criteria for 64-bit
> x86, in fact. However, you're generally going to do so by
> entering 32-bit mode.
I didn't want to enter 32-bit mode.
> E.g., the system might boot up and run in
> 64-bit mode in the kernel (ring 0), but then execute user code
> in 32-bit mode (e.g., in ring 3).
> >Ie are sufficient instructions available for a general purpose application?
> >
> >I would be running under 64 bit EFI
> >
> >Using only memory below 4 GB
> >
> >And without paging.
> It's unclear what you mean here: if you're in long mode, you
> must enable paging. That doesn't mean that you can't run 32-bit
> code, but the machine must be an architecturally well-defined
> state.
Ok, I didn't want to manipulate page tables then. I'll just
accept whatever EFI gives me.
> It's unclear what you mean when you say, "I would be running
> under 64 bit EFI": do you mean you'd be executing something
> integrated with UEFI (such as a DXE provider?) or do you mean
> that that's just how your machine would boot?
That's how my machine would boot, and I would be
using the EFI API, basically as the OS.
> >The 32 bit code would be in a.out format and I would load it myself.
> Before one can really address this, one needs more contextual
> information. Would this code be run in user mode?
I don't know. Before you exit boot services, are you in
user mode?
> If so, what
> you could do is simply leave the kernel and enter a 32-bit
> user mode executing this code (e.g., in a 32-bit code segment).
>
> But if begs the question: if you're willing to both write your
> own compiler and recompile your code, why not simply build it
> as 64-bit code and avoid the hassle?
I am only running in 64-bit mode under protest.
I consider 64-bit overkill and dangerous.
If we ever have to restart the computer industry, 32-bit will
come first, and that's where I want to be.
In "Life on Earth v2" there could be a 1000 year gap between
32-bit and 64-bit.
It may not be v2, it may simply be an indigenous North Korean
computer industry. Or Filipino or African.
I'm particularly interested in a Filipino software industry, but
the hardware would presumably follow that. The Soviets had
something too.
There could also be a 1000 year gap between 16-bit and 32-bit,
but that's not the problem I'm addressing at the moment.
Massive mainframes were 32-bit and had 2 MB of memory
circa 1967.
BFN. Paul.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
