OSDev.org

Octocontrabass wrote:I don't think it matters where you put it since you're the only one who will implement it.

Is there a logical place to extend UEFI in the manner I described? I'm after a combination of - where would the official UEFI people put it if they wanted to support this map 4-8 to 0-4 facility as a call, and, given that I need to preempt them - where can I preempt them? ie is there a set of flags somewhere that they are using to say what options are in use, and then perhaps I can use the last, currently unused flag?

It's not logical to extend UEFI in the way you described. UEFI is built on the assumption that paging will be disabled while boot services are running.

The closest existing functionality in UEFI is SetVirtualAddressMap(). Based on that example, you would add a function pointer in the boot services table and increase the version number in the table, but that conflicts with new versions of the UEFI specification.

To avoid conflicts with future UEFI versions, you would need to set it up as a protocol, but it doesn't make sense for a protocol to modify the memory map.

if they wanted to support this map 4-8 to 0-4 facility as a call

They won't, because it would be completely backwards-incompatible.

UEFI already specifies an identity mapping for physical memory. Since multiple UEFI applications and drivers can be resident, and some of them or all of them may expect the complete identity mapping to be available, it is not possible for any one application to request an alternate mapping arrangement. The entire UEFI ecosystem would need to change; it would be a new, backwards incompatible version of UEFI, and any existing UEFI applications (including OS bootloaders) would need to be updated to support it.

In addition, there are good reasons not to allow such a mapping. For one, it precludes access to the 4gb-8gb physical range, which might include device memory etc, unless it is re-mapped elsewhere, which requires additional complexity (applications would need to be able to query the mapping, or it would need to be standardised in some way). Secondly, it would prevent the UEFI environment from using the 4gb-8gb linear range for applications, since at any point an application might request (via your proposed call) to have that range re-mapped.

On top of all that, the only purpose of supporting is for some vague reason of being able to run a very limited set of 32-bit x86 applications, using a limited subset of instructions, without switching to compatibility mode or 32-bit protected mode, even though switching mode is already allowed. What benefit does this bring? Why not just switch mode and switch back as and when necessary to call into UEFI services?

ie is there a set of flags somewhere that they are using to say what options are in use, and then perhaps I can use the last, currently unused flag?

No, because UEFI exports a consistent environment to all applications and individual applications generally can't change any global mode in a way that would impact other running applications, since doing so could obviously cause problems.

Is there a logical place to extend UEFI in the manner I described?

Add a function in the boot services table, I guess. Or expose it via a new protocol and have an application which wants to use it call LocateProtocol, for example.

davmac314 wrote:

if they wanted to support this map 4-8 to 0-4 facility as a call

They won't, because it would be completely backwards-incompatible.

UEFI already specifies an identity mapping for physical memory. Since multiple UEFI applications and drivers can be resident, and some of them or all of them may expect the complete identity mapping to be available, it is not possible for any one application to request an alternate mapping arrangement. The entire UEFI ecosystem would need to change; it would be a new, backwards incompatible version of UEFI, and any existing UEFI applications (including OS bootloaders) would need to be updated to support it.

Sorry - I'm not disputing anything you are saying, but I am confused. Perhaps we are talking cross-purposes.

Why would any existing applications be affected at all?

Nobody gets the 4-8 to 0-4 mapping unless they explicitly make the requested call.

To start with, I will be the only person making that explicit call. And that will indeed be my bootloader, and then you can indeed run 32-bit applications. Nothing more, nothing less.

In addition, there are good reasons not to allow such a mapping. For one, it precludes access to the 4gb-8gb physical range, which might include device memory etc, unless it is re-mapped elsewhere, which requires additional complexity (applications would need to be able to query the mapping, or it would need to be standardised in some way). Secondly, it would prevent the UEFI environment from using the 4gb-8gb linear range for applications, since at any point an application might request (via your proposed call) to have that range re-mapped.

This wouldn't be "at any point" - it's not for application use - it's for the bootloader to switch to this new configuration - to run 32-bit programs (only - at least, nominally). Access to any device memory would be under UEFI control. I do a conout call, and it is UEFI that knows where to write that to device memory, including any remapping that UEFI itself put in place. Am I missing something?

On top of all that, the only purpose of supporting is for some vague reason of being able to run a very limited set of 32-bit x86 applications, using a limited subset of instructions, without switching to compatibility mode or 32-bit protected mode, even though switching mode is already allowed. What benefit does this bring? Why not just switch mode and switch back as and when necessary to call into UEFI services?

1. This allows CM32 to be removed from the processor entirely, making it simpler/cheaper.
2. It may actually be LM64 that is removed from the processor entirely, and I'll switch in a 32-bit processor that looks mostly, but not entirely, like the 80386 (extra instructions are required to manipulate R8 and R9)
3. I don't need to run - potentially for a long time - with interrupts disabled.
4. I don't need to run any privileged instructions.
5. I don't need any complicated code - it's all simple UEFI calls (although this could be mitigated by UEFI itself providing a call to switch to CM32 - and indeed, this might be a better approach regardless - even if that call to activate CM32 in reality just does a remapping of 4-8 to 0-4 and relies on the software using the limited subset of instructions - and indeed, this could be configurable).

Add a function in the boot services table, I guess.

This would require a specific spot that may clash with other extensions, and I can't detect whether the extension is actually there, without crashing, right?

Or expose it via a new protocol and have an application which wants to use it call LocateProtocol, for example.

This sounds like what I should do - give it a unique name, like "Go32", and then detect if it exists. Thanks.

kerravon wrote: 2. It may actually be LM64 that is removed from the processor entirely, and I'll switch in a 32-bit processor that looks mostly, but not entirely, like the 80386 (extra instructions are required to manipulate R8 and R9)

Actually, there could be another UEFI call - or a suite of other UEFI calls - to change the calling convention for all/some functions so that a literal 80386 could be used to replace the x64. Or perhaps a call-convention-converter could be one of the UEFI calls?

Why would any existing applications be affected at all?

Nobody gets the 4-8 to 0-4 mapping unless they explicitly make the requested call.

In a UEFI environment all running applications share the same page mapping. There is no isolation. If one application requests a funky mapping, it's forced upon all other running applications as well.

To start with, I will be the only person making that explicit call. And that will indeed be my bootloader, and then you can indeed run 32-bit applications. Nothing more, nothing less.

If it's a bootloader, exit boot services and setup whatever mapping you please.

If you continue running in the boot services environment, you don't know other applications you are sharing it with. They may have been started before your "bootloader" was. Some of them may be drivers.

This wouldn't be "at any point" - it's not for application use - it's for the bootloader to switch to this new configuration - to run 32-bit programs (only - at least, nominally). Access to any device memory would be under UEFI control.

This feels like wrong use of the term "bootloader". A boot loader typically uses UEFI only to get established and assist in loading the kernel. Once that's done, it exits boot services, sets up whatever mode/mapping is required, and executes the kernel. Device memory is (in general) no longer under UEFI control the moment you exit boot services.

So, you're talking about a UEFI application. And a UEFI application doesn't have sole use of boot services.

Even if you don't agree with the terminology, it's the case that if you aren't exiting boot services, you're sharing the environment with other UEFI applications and drivers, and existing UEFI applications/drivers are not designed to work when memory isn't identity mapped.

1. This allows CM32 to be removed from the processor entirely, making it simpler/cheaper.
2. It may actually be LM64 that is removed from the processor entirely, and I'll switch in a 32-bit processor that looks mostly, but not entirely, like the 80386 (extra instructions are required to manipulate R8 and R9)

So you're talking custom architecture. Why bother with UEFI at all? Write whatever firmware you want. Or, sure, make whatever modifications you want. Or use a 32-bit UEFI firmware and forget about this whole extension stuff.

3. I don't need to run - potentially for a long time - with interrupts disabled.
4. I don't need to run any privileged instructions.
5. I don't need any complicated code - it's all simple UEFI calls (although this could be mitigated by UEFI itself providing a call to switch to CM32 - and indeed, this might be a better approach regardless - even if that call to activate CM32 in reality just does a remapping of 4-8 to 0-4 and relies on the software using the limited subset of instructions - and indeed, this could be configurable).

To be honest I don't find any of those compelling. [3] in particular isn't the case even if you do switch mode. [4] - so what? [5] - we're talking library/runtime code, it's not like you write it fresh for every application, and it's really not that complicated.

This would require a specific spot that may clash with other extensions, and I can't detect whether the extension is actually there, without crashing, right?

I mean, what you've described is "not UEFI". So there aren't any extensions for it. There isn't any existing software for it. You have to modify the firmware anyway, do whatever you want.

Forgive me for saying so but it seems like you're so hell-bent on a particular solution that you've forgotten what the problem is. It's certainly not clear to me what problem you're trying to solve.

kerravon wrote:Actually, there could be another UEFI call - or a suite of other UEFI calls - to change the calling convention for all/some functions

No, because, again, a UEFI application doesn't have sole, exclusive access to boot services and other applications aren't going to be able to deal with the calling convention being switched out from underneath them.

so that a literal 80386 could be used to replace the x64.

1. How would you get a literal 80386 to boot and run x64 UEFI firmware?
2. If you had an 80386 and were dead-set on using UEFI, why wouldn't you just run a 32-bit UEFI firmware? And then you can happily run 32-bit code without any funky mapping hacks or "extensions", no need to change calling conventions, etc.

davmac314 wrote: In a UEFI environment all running applications share the same page mapping. There is no isolation. If one application requests a funky mapping, it's forced upon all other running applications as well.

I'm not expecting other "applications" to be running. This is a dead PC. I stick in my USB stick with my bootloader/kernel/apps (all on the USB stick) and fire it up. The same as I have traditionally done with a traditional BIOS.

If it's a bootloader, exit boot services and setup whatever mapping you please.

I don't want to exit boot services. That's what I'm using as a BIOS and/or OS.

If you continue running in the boot services environment, you don't know other applications you are sharing it with. They may have been started before your "bootloader" was. Some of them may be drivers.

Well - I expect that to be part of the UEFI environment. So yes, they can't access the 4-8 GiB region. My UEFI would need an option to make that physical memory inaccessible to other components as it can potentially be remapped.

This feels like wrong use of the term "bootloader". A boot loader typically uses UEFI only to get established and assist in loading the kernel. Once that's done, it exits boot services, sets up whatever mode/mapping is required, and executes the kernel. Device memory is (in general) no longer under UEFI control the moment you exit boot services.

Ok, so terminology. It's unclear what UCX64 actually is. It currently has the ability to run some Win64 executables. It does this with minimal code. Basically converting a Win64 call to msvcrt.dll into (eventually) a UEFI call. It also needs to actually load the Win64 executables into memory since this file format - or at least the DLLs (msvcrt.dll) are not known to UEFI. But both memory management and file management have been left to UEFI to do (at least currently - I do have my own versions of both of these things that I could switch in).

1. This allows CM32 to be removed from the processor entirely, making it simpler/cheaper.
2. It may actually be LM64 that is removed from the processor entirely, and I'll switch in a 32-bit processor that looks mostly, but not entirely, like the 80386 (extra instructions are required to manipulate R8 and R9)

So you're talking custom architecture. Why bother with UEFI at all? Write whatever firmware you want.

First it will work with existing x64 processors and a slightly modified UEFI. I'm not trying to change the world, I'm just trying to sneak in 32-bit software with minimal fuss.

THEN, someone else can make a cheaper 32-bit or cheaper 64-bit processor, and my software will continue to work unchanged.

3. I don't need to run - potentially for a long time - with interrupts disabled.

To be honest I don't find any of those compelling. [3] in particular isn't the case even if you do switch mode.

What do you mean? In my design I don't exit boot services. Therefore I need to disable interrupts before switching to CM32, and return to LM64 before reenabling them to do a UEFI call. If I stay in LM64 (running unusual 32-bit code), I don't need to disable interrupts at all - especially not for a long time.

This would require a specific spot that may clash with other extensions, and I can't detect whether the extension is actually there, without crashing, right?

I mean, what you've described is "not UEFI". So there aren't any extensions for it. There isn't any existing software for it. You have to modify the firmware anyway, do whatever you want.

The software will exist, rapidly, as soon as I have a C compiler that has been modified to produce the "unusual assembler". I have standard C90 code already, standing by. In fact, a lot of it will probably run without any UEFI changes, because negative indexes aren't very common.

Forgive me for saying so but it seems like you're so hell-bent on a particular solution that you've forgotten what the problem is. It's certainly not clear to me what problem you're trying to solve.

Running Win32 instead of Win64 software under 64-bit UEFI. If you look at http://pdos.org at the bottom of the UCX64 section, I have that already as proof of concept. Negative indexes won't work though - but I don't have negative indexes.

At a later date ... run that exact same Win32 software on an 80386.

Or ... make that an earlier date ... 1986. Replace the BIOS with 64-bit UEFI in 1986. Or create a 64-bit UEFI layer on top of the BIOS, in 1986. And when I say "64-bit UEFI" - it will be ready for UEFI - parameters on the stack will occupy 8 bytes, the stack will always be 16-byte aligned, but back in 1986 it will actually be 32-bit. But standing by ready for genuine 64-bit UEFI.

1. How would you get a literal 80386 to boot and run x64 UEFI firmware?

The details of the UEFI implementation and the processor used are hidden from the bootloader/kernel/win32 application author and are out of scope. These people just need to know what rules to follow to work on both an 80386 and x64.

2. If you had an 80386 and were dead-set on using UEFI, why wouldn't you just run a 32-bit UEFI firmware? And then you can happily run 32-bit code without any funky mapping hacks or "extensions", no need to change calling conventions, etc.

That would require both an 80386 and x64 version of every single 32-bit program I wrote, starting in 1986.

The goal is for a single executable to run on either an 80386 or an x64 in LM64, and without conditional execution/duplication/layers (in my executables - I don't really care what happens outside of my executables).

kerravon wrote:Well - I expect that to be part of the UEFI environment.

But they often aren't. PCI devices will provide their own drivers inside option ROMs. Heck, even drivers built into the main firmware ROM are often binary blobs provided by the hardware vendor. You won't be modifying those.

kerravon wrote:First it will work with existing x64 processors and a slightly modified UEFI. I'm not trying to change the world, I'm just trying to sneak in 32-bit software with minimal fuss.

You can already do that with 32-bit compatibility mode and unmodified UEFI. It also doesn't require a special compiler, so you can run existing binaries.

kerravon wrote:In my design I don't exit boot services. Therefore I need to disable interrupts before switching to CM32, and return to LM64 before reenabling them to do a UEFI call.

If you install wrappers around the UEFI ISRs, you can enable interrupts while you're in 32-bit compatibility mode. The interrupts will switch to 64-bit mode, and your wrappers will be responsible for restoring the rest of the UEFI environment before calling the UEFI ISR and restoring the rest of your environment before returning to 32-bit compatibility mode.

Or exit boot services. It sounds like you don't actually need them.

kerravon wrote:That would require both an 80386 and x64 version of every single 32-bit program I wrote, starting in 1986.

Not if you use 32-bit compatibility mode.

kerravon wrote:The goal is for a single executable to run on either an 80386 or an x64 in LM64, and without conditional execution/duplication/layers (in my executables - I don't really care what happens outside of my executables).

That's what 32-bit compatibility mode is for.

kerravon wrote:

davmac314 wrote: In a UEFI environment all running applications share the same page mapping. There is no isolation. If one application requests a funky mapping, it's forced upon all other running applications as well.

I'm not expecting other "applications" to be running. This is a dead PC. I stick in my USB stick with my bootloader/kernel/apps (all on the USB stick) and fire it up. The same as I have traditionally done with a traditional BIOS.

As I said, they could be drivers. These can come from option ROMs on hardware.

If you are talking about a particular PC, then you don't need anything added to the official UEFI specs; just implement something that works on that PC.

If you are not talking about a particular PC, then you can't control what else is sharing the boot services environment with your bootloader and you certainly can't expect the UEFI organisation in being interested in incorporating an extension which will literally support only this thing you are developing and that no other vendor wants or needs.

If it's a bootloader, exit boot services and setup whatever mapping you please.

I don't want to exit boot services. That's what I'm using as a BIOS and/or OS.

Then, as I said, you are sharing the environment with other applications/drivers and you can't change memory mappings.

If you continue running in the boot services environment, you don't know other applications you are sharing it with. They may have been started before your "bootloader" was. Some of them may be drivers.

Well - I expect that to be part of the UEFI environment. So yes, they can't access the 4-8 GiB region. My UEFI would need an option to make that physical memory inaccessible to other components as it can potentially be remapped.

In a UEFI environment, applications/drivers can access the entirety of physical memory via an identity mapping. That's part of the specification.

If you are talking about a custom firmware (perhaps that is a modification of a UEFI firmware, or at least is based partly on the UEFI spec) then you are free to do whatever you want. But it is then not UEFI.

It's still not clear to me whether you are talking about a custom firmware or not. You were against modifying the boot services table because it would conflict with "extensions", which implies that you're not in control of the firmware. But you're also talking about making significant changes that would require a custom firmware.

This feels like wrong use of the term "bootloader". A boot loader typically uses UEFI only to get established and assist in loading the kernel. Once that's done, it exits boot services, sets up whatever mode/mapping is required, and executes the kernel. Device memory is (in general) no longer under UEFI control the moment you exit boot services.

Ok, so terminology. It's unclear what UCX64 actually is. It currently has the ability to run some Win64 executables. It does this with minimal code. Basically converting a Win64 call to msvcrt.dll into (eventually) a UEFI call. It also needs to actually load the Win64 executables into memory since this file format - or at least the DLLs (msvcrt.dll) are not known to UEFI. But both memory management and file management have been left to UEFI to do (at least currently - I do have my own versions of both of these things that I could switch in).

Ok. In my view at least, if it's using UEFI boot services, it's a UEFI application.

So you're talking custom architecture. Why bother with UEFI at all? Write whatever firmware you want.

First it will work with existing x64 processors and a slightly modified UEFI. I'm not trying to change the world, I'm just trying to sneak in 32-bit software with minimal fuss.

THEN, someone else can make a cheaper 32-bit or cheaper 64-bit processor, and my software will continue to work unchanged.

Ok, thanks for explaining. The question "why" still remains.

3. I don't need to run - potentially for a long time - with interrupts disabled.

To be honest I don't find any of those compelling. [3] in particular isn't the case even if you do switch mode.

What do you mean? In my design I don't exit boot services. Therefore I need to disable interrupts before switching to CM32, and return to LM64 before reenabling them to do a UEFI call. If I stay in LM64 (running unusual 32-bit code), I don't need to disable interrupts at all - especially not for a long time.

There is no requirement to disable interrupts before switching mode. You can catch interrupts, switch back to LM64, and dispatch the firmware's interrupt handler.

Forgive me for saying so but it seems like you're so hell-bent on a particular solution that you've forgotten what the problem is. It's certainly not clear to me what problem you're trying to solve.

Running Win32 instead of Win64 software under 64-bit UEFI. If you look at http://pdos.org at the bottom of the UCX64 section, I have that already as proof of concept. Negative indexes won't work though - but I don't have negative indexes.

Yeah but, why?

And to pick a bone: by "Win32 software" I gather you mean "a crafted set of software that would also run in a Win32 environment", not "all Win32 software".

Or ... make that an earlier date ... 1986. Replace the BIOS with 64-bit UEFI in 1986. Or create a 64-bit UEFI layer on top of the BIOS, in 1986. And when I say "64-bit UEFI" - it will be ready for UEFI - parameters on the stack will occupy 8 bytes, the stack will always be 16-byte aligned, but back in 1986 it will actually be 32-bit. But standing by ready for genuine 64-bit UEFI.

This is hard to interpret. I think you mean that you want to create executables which would feasibly run on 1986 hardware, and then also run under modern 64-bit x64 UEFI (or at least some modification of it)?

1. How would you get a literal 80386 to boot and run x64 UEFI firmware?

The details of the UEFI implementation and the processor used are hidden from the bootloader/kernel/win32 application author and are out of scope. These people just need to know what rules to follow to work on both an 80386 and x64.

But that doesn't answer the question. Do you mean: you would expect to use a custom firmware when running on a literal 80386? Something that was essentially 32-bit UEFI but used 64-bit calling conventions (optionally - I guess that's what you meant when you talked about a call to change the calling convention)?

The goal is for a single executable to run on either an 80386 or an x64 in LM64, and without conditional execution/duplication/layers (in my executables - I don't really care what happens outside of my executables).

Why do you need to do this? Is it really worth the trouble (edit: ... to do it without just using compatibility mode)?

Octocontrabass wrote:Or exit boot services. It sounds like you don't actually need them.

Why do you think I don't need boot services? That's what I'm using to access disks and screen. Currrently I'm even accessing individual files with them rather than using my own FAT code.

That's what 32-bit compatibility mode is for.

I agree that CM32 - at least on the face of it - is the better option, which is why I said I would probably switch to that. However, I wanted to flesh out the LM64 solution in case one day CM32 disappears - or perhaps cheaper x64 processors no longer provide it.

davmac314 wrote:If you are talking about a particular PC, then you don't need anything added to the official UEFI specs; just implement something that works on that PC.

It's as many PCs as possible, without compromising the design, so I'd like it put into the UEFI specs (or an "unauthorized" change that eventually makes its way into the specs by "popular demand").

If you are not talking about a particular PC, then you can't control what else is sharing the boot services environment with your bootloader and you certainly can't expect the UEFI organisation in being interested in incorporating an extension which will literally support only this thing you are developing and that no other vendor wants or needs.

You never know what people are interested in. That's why retro programming is a thing.

If you are talking about a custom firmware (perhaps that is a modification of a UEFI firmware, or at least is based partly on the UEFI spec) then you are free to do whatever you want. But it is then not UEFI.

Oh sure - it would start life as not-UEFI, I just don't want to paint myself into a corner preventing it from being incorporated into the official UEFI at a later date (ie after it is proven to work, becomes popular, inspires cheaper 32-bit processors etc).

It's still not clear to me whether you are talking about a custom firmware or not. You were against modifying the boot services table because it would conflict with "extensions", which implies that you're not in control of the firmware. But you're also talking about making significant changes that would require a custom firmware.

I wasn't expecting the changes to be significant. The UEFI can be configured to tell everyone that there is only 4 GiB of physical RAM. In fact - that's all I actually need. I'm only running 32-bit software, so I just need all memory above 4 GiB disabled, and then the 4-8 GiB region to be mapped to 0-4.

Surely it's not difficult for the main UEFI to tell all the drivers that there is only 4 GiB of usable memory?

Note that in the future it would be nice to be able to access more than 4 GiB of physical memory (and be able to run genuine 64-bit programs), perhaps using a subset of drivers that know how to handle this situation, but it's not a priority.

So you're talking custom architecture. Why bother with UEFI at all? Write whatever firmware you want.

First it will work with existing x64 processors and a slightly modified UEFI. I'm not trying to change the world, I'm just trying to sneak in 32-bit software with minimal fuss.

THEN, someone else can make a cheaper 32-bit or cheaper 64-bit processor, and my software will continue to work unchanged.

Ok, thanks for explaining. The question "why" still remains.

Why use UEFI? My code is written to use UEFI. I would be quite happy to use the BIOS, as I have for 30 years, but on some machines there is no longer a BIOS. Since I'm being forced to upgrade anyway, I was going to make the most of it and try to keep my 32-bit software. I'm happy to recompile it all (once) when I have an appropriate C compiler that generates perfectly valid (but a bit odd) 80386 code.

Forgive me for saying so but it seems like you're so hell-bent on a particular solution that you've forgotten what the problem is. It's certainly not clear to me what problem you're trying to solve.

Running Win32 instead of Win64 software under 64-bit UEFI. If you look at http://pdos.org at the bottom of the UCX64 section, I have that already as proof of concept. Negative indexes won't work though - but I don't have negative indexes.

Yeah but, why?

As a fallback in case CM32 disappears (or is too difficult to get into). As another option. As I have said, CM32 appears to be the superior solution, so I'll probably do that, eventually. Right at the moment I am doing 64-bit Windows programming for a totally unrelated reason (a public domain C compiler has been made available), so that has priority over all my 32-bit software. THAT is what has inspired me to do 64-bit at all. I was happy to continue doing 32-bit. I don't come close to using 4 GiB of memory. People even chided me for using more than 16 MiB (I spent a lot of time lifting that restriction on MVS 3.8J (sort of)).

And to pick a bone: by "Win32 software" I gather you mean "a crafted set of software that would also run in a Win32 environment", not "all Win32 software".

Oh yes, absolutely. Just a subset of Win32 console mode applications - the ones that I am actually interested in - as a replacement for MSDOS.

Or ... make that an earlier date ... 1986. Replace the BIOS with 64-bit UEFI in 1986. Or create a 64-bit UEFI layer on top of the BIOS, in 1986. And when I say "64-bit UEFI" - it will be ready for UEFI - parameters on the stack will occupy 8 bytes, the stack will always be 16-byte aligned, but back in 1986 it will actually be 32-bit. But standing by ready for genuine 64-bit UEFI.

This is hard to interpret. I think you mean that you want to create executables which would feasibly run on 1986 hardware, and then also run under modern 64-bit x64 UEFI (or at least some modification of it)?

Exactly correct. Apologies I am not very good at expressing myself (at least based on responses I get - it seems perfectly fine to me when I write it).

1. How would you get a literal 80386 to boot and run x64 UEFI firmware?

The details of the UEFI implementation and the processor used are hidden from the bootloader/kernel/win32 application author and are out of scope. These people just need to know what rules to follow to work on both an 80386 and x64.

But that doesn't answer the question. Do you mean: you would expect to use a custom firmware when running on a literal 80386? Something that was essentially 32-bit UEFI but used 64-bit calling conventions (optionally - I guess that's what you meant when you talked about a call to change the calling convention)?

Yep, exactly correct again.

The goal is for a single executable to run on either an 80386 or an x64 in LM64, and without conditional execution/duplication/layers (in my executables - I don't really care what happens outside of my executables).

Why do you need to do this? Is it really worth the trouble (edit: ... to do it without just using compatibility mode)?

It will only become evident that I should have done this all along when CM32 disappears from processors for cost-saving reasons (**).

Similar to how 16-bit MSDOS software suddenly stopped running at all, instead of the alternative which would have been for the exact same 16-bit binary to suddenly be able to access 4 GiB (*) of memory.

(*) Or 512 MB anyway, because you run out of selectors on an actual 80386 - but there could have been (and could still be) more selectors (or an alternative technique - but not emulation) on a non-80386.

(**) And the cheap processor could be a RISC too - it only needs to support the instructions my (non-existent) C compiler actually produces.

kerravon wrote:

If you are talking about a custom firmware (perhaps that is a modification of a UEFI firmware, or at least is based partly on the UEFI spec) then you are free to do whatever you want. But it is then not UEFI.

Oh sure - it would start life as not-UEFI, I just don't want to paint myself into a corner preventing it from being incorporated into the official UEFI at a later date (ie after it is proven to work, becomes popular, inspires cheaper 32-bit processors etc).

Ok, so I'm going to extrapolate again because I'm still confused about what you want to do. Correct me if I'm wrong. You want to develop a modified firmware for a particular x64-based system (at first) so you can run specially crafted executables on it that also will run under a win32 environment, and which in theory could also later be made to run on an 80386 (for example) also with a modified firmware.

You then want to modify the firmware for other x64-based systems so you can do the same thing on them. (This seems like a lot of effort, incidentally). And eventually get UEFI to accept your change into a newer version of the UEFI standard, so that hopefully it gets implemented into a broad range of firmware by the vendors rather than requiring yourself to implement the firmware changes.

I wasn't expecting the changes to be significant. The UEFI can be configured to tell everyone that there is only 4 GiB of physical RAM. In fact - that's all I actually need. I'm only running 32-bit software, so I just need all memory above 4 GiB disabled, and then the 4-8 GiB region to be mapped to 0-4.

Surely it's not difficult for the main UEFI to tell all the drivers that there is only 4 GiB of usable memory?

Where would you even start? Do you have a plan for how you are going to modify the firmware for an existing system design (board)? What sort of board are you going to target, does it have open firmware? If it doesn't, how will you modify the firmware? If it does, how do you plan to do the same modifications on other systems which don't have open firmware?

Ok, thanks for explaining. The question "why" still remains.

Why use UEFI? My code is written to use UEFI. I would be quite happy to use the BIOS, as I have for 30 years, but on some machines there is no longer a BIOS. Since I'm being forced to upgrade anyway, I was going to make the most of it and try to keep my 32-bit software. I'm happy to recompile it all (once) when I have an appropriate C compiler that generates perfectly valid (but a bit odd) 80386 code.

No, why run Win32 software under 64-bit UEFI? Why not just compile it as a 64-bit UEFI application, or even as a Win64 application? In short: why's it so important that you can run a single executable on two very different architectures?

kerravon wrote:Why do you think I don't need boot services? That's what I'm using to access disks and screen. Currrently I'm even accessing individual files with them rather than using my own FAT code.

You're clearly capable of writing your own drivers to access disks and screen. So why don't you do that? Then it won't matter what the firmware is doing because you won't be relying on the firmware.

davmac314 wrote:

kerravon wrote:

If you are talking about a custom firmware (perhaps that is a modification of a UEFI firmware, or at least is based partly on the UEFI spec) then you are free to do whatever you want. But it is then not UEFI.

Oh sure - it would start life as not-UEFI, I just don't want to paint myself into a corner preventing it from being incorporated into the official UEFI at a later date (ie after it is proven to work, becomes popular, inspires cheaper 32-bit processors etc).

Ok, so I'm going to extrapolate again because I'm still confused about what you want to do. Correct me if I'm wrong. You want to develop a modified firmware for a particular x64-based system (at first) so you can run specially crafted executables on it that also will run under a win32 environment, and which in theory could also later be made to run on an 80386 (for example) also with a modified firmware.

You then want to modify the firmware for other x64-based systems so you can do the same thing on them. (This seems like a lot of effort, incidentally). And eventually get UEFI to accept your change into a newer version of the UEFI standard, so that hopefully it gets implemented into a broad range of firmware by the vendors rather than requiring yourself to implement the firmware changes.

Everything is correct except for "I want to modify the firmware for other x64-based systems". I will (nominally) only do one, for proof of concept. If the underlying Win32 software takes off (not likely - but that's what I wish to prepare for) - then the consumers will demand the one PC that actually works, all the other PC vendors will update their firmware to try to get back their market share, the UEFI standards committee will update their standards. My focus is just on the first part of that - the Win32 software - and also to prove that it works (or can work) on UEFI (prove both LM64 and CM32, ideally).

Surely it's not difficult for the main UEFI to tell all the drivers that there is only 4 GiB of usable memory?

Where would you even start? Do you have a plan for how you are going to modify the firmware for an existing system design (board)? What sort of board are you going to target, does it have open firmware? If it doesn't, how will you modify the firmware? If it does, how do you plan to do the same modifications on other systems which don't have open firmware?

As per above - it would be the vendor making this minimal change, not me.

Why use UEFI? My code is written to use UEFI. I would be quite happy to use the BIOS, as I have for 30 years, but on some machines there is no longer a BIOS. Since I'm being forced to upgrade anyway, I was going to make the most of it and try to keep my 32-bit software. I'm happy to recompile it all (once) when I have an appropriate C compiler that generates perfectly valid (but a bit odd) 80386 code.

No, why run Win32 software under 64-bit UEFI? Why not just compile it as a 64-bit UEFI application, or even as a Win64 application? In short: why's it so important that you can run a single executable on two very different architectures?

What I want is programming rules issued in 1986 that would allow me to future-proof my executables. I have also constructed rules for the mainframe to do the same thing. The mainframe was much easier - they didn't do what x64 did - they didn't invalidate any 32-bit instructions. It's quite odd to me to see instructions invalidated - but if that's what manufacturers are allowed to do (or, in 1986, going to do), so be it. I'll write my software according to the rules.

I expect to build a PE32+ executable in 1986, according to the rules (rules which were formulated between 1980 and 1985), and have it work forever. I do not expect to be forced to recompile it post-1986.

"Forever" will be "until LM64 is permanently retired".