Does anyone know how to execute the machine code using free pascal

[PascalDragon]

Hmm. https://wiki.osdev.org/UEFI points at a couple of toolchains, using GCC or LLVM. Certainly in the GCC case that almost certainly implies use of the standard linker even if there is some subsequent operation to prepare a final file, so even if this is not a "custom toolchain" per se it would be reasonable to expect OP to already be familiar with the linker syntax and- in particular- the scripts that drive it.

UEFI simply runs PE/COFF binaries. So everything that can generate PE/COFF can also be used to generate UEFI binaries.

Subject to writing custom initialisation code etc., FPC should be able to do the job. Or rather, OP should be able to do the job using FPC >:-)

Considering that TYDQ already extended FPC to compile UEFI binaries... (look at some of their other threads if you're interested)

[TYDQ]

Hmm. https://wiki.osdev.org/UEFI points at a couple of toolchains, using GCC or LLVM. Certainly in the GCC case that almost certainly implies use of the standard linker even if there is some subsequent operation to prepare a final file, so even if this is not a "custom toolchain" per se it would be reasonable to expect OP to already be familiar with the linker syntax and- in particular- the scripts that drive it.

UEFI simply runs PE/COFF binaries. So everything that can generate PE/COFF can also be used to generate UEFI binaries.

Subject to writing custom initialisation code etc., FPC should be able to do the job. Or rather, OP should be able to do the job using FPC >:-)

Considering that TYDQ already extended FPC to compile UEFI binaries... (look at some of their other threads if you're interested)

Do you have the plan to just add the support of PE binaries in every architecture targets?I cannot compile the UEFI binaries in targets such as loongarch(I can only complie UEFI binaries with fpc and objcopy in linux in x86_64 target and aarch64 target).I demanded your support for PE/COFF support in every target!

[MarkMLl]

Considering that TYDQ already extended FPC to compile UEFI binaries... (look at some of their other threads if you're interested)

I've seen them although I've not followed them in detail. But now is really a very, /very/ odd time for him to admit that he'd not fully conversant with the documentation... and the same happened in another thread where he was asking about writing an assembler.

@TYDQ: Are you a single developer, or are multiple people using the same login? Your activity times span about 16 hours with two peaks suggesting different timezones.

Please excuse the intrusion, but the open source projects community has reason to be wary after the xz/SSH hack https://hackaday.com/2024/04/05/this-week-in-security-xz-att-and-letters-of-marque/

MarkMLl

[TYDQ]

Considering that TYDQ already extended FPC to compile UEFI binaries... (look at some of their other threads if you're interested)

I've seen them although I've not followed them in detail. But now is really a very, /very/ odd time for him to admit that he'd not fully conversant with the documentation... and the same happened in another thread where he was asking about writing an assembler.

@TYDQ: Are you a single developer, or are multiple people using the same login? Your activity times span about 16 hours with two peaks suggesting different timezones.

Please excuse the intrusion, but the open source projects community has reason to be wary after the xz/SSH hack https://hackaday.com/2024/04/05/this-week-in-security-xz-att-and-letters-of-marque/

MarkMLl

I am a single developer,not multiple people using the same login.I am using the VPN to enter the forum otherwise I cannot enter this website in China Mainland.

[MarkMLl]

I am a single developer,not multiple people using the same login.I am using the VPN to enter the forum otherwise I cannot enter this website in China Mainland.

Thanks for the update, I also noticed your mention of Loongson. It is strange that access to a purely-technical forum is being blocked, particularly since in the past Chinese developers were here trying to accelerate development of the MIPS target.

Out of curiosity, do you have an x86 or x86_64 system to use as a UEFI target, or are you relying on Qemu?

MarkMLl

[TYDQ]

I am a single developer,not multiple people using the same login.I am using the VPN to enter the forum otherwise I cannot enter this website in China Mainland.

Thanks for the update, I also noticed your mention of Loongson. It is strange that access to a purely-technical forum is being blocked, particularly since in the past Chinese developers were here trying to accelerate development of the MIPS target.

Out of curiosity, do you have an x86 or x86_64 system to use as a UEFI target, or are you relying on Qemu?

MarkMLl

I am relying on QEMU for testing x86_64 system.My host is x86_64 windows and my linux is Fedora 40 in VMWare virtual machine.
Wait,If I don't use VPN,the access of lazarus forum will be slower and unstable and to be faster and more stable,I use the VPN.For China Mainland,If I want to access to the foreign website,It will be slow and unstable such as accessing github.

[MarkMLl]

I am relying on QEMU for testing x86_64 system.

Probably a wise choice, it's less easy to break it beyond repair :-)

MarkMLl

[PascalDragon]

Hmm. https://wiki.osdev.org/UEFI points at a couple of toolchains, using GCC or LLVM. Certainly in the GCC case that almost certainly implies use of the standard linker even if there is some subsequent operation to prepare a final file, so even if this is not a "custom toolchain" per se it would be reasonable to expect OP to already be familiar with the linker syntax and- in particular- the scripts that drive it.

UEFI simply runs PE/COFF binaries. So everything that can generate PE/COFF can also be used to generate UEFI binaries.

Subject to writing custom initialisation code etc., FPC should be able to do the job. Or rather, OP should be able to do the job using FPC >:-)

Considering that TYDQ already extended FPC to compile UEFI binaries... (look at some of their other threads if you're interested)

Do you have the plan to just add the support of PE binaries in every architecture targets?

If there would be an assembler out there (e.g. GNU as or llvm) then this would be possible. Otherwise someone has to implement an internal assembler for the architecture in question so that the internal COFF output writer can be used. But that definitely won't be me, except maybe for aarch64.

I demanded your support for PE/COFF support in every target!

I'm assuming that this is some mistranslation, because if you think that you can demand anything from me, then you're definitely mistaken.

[TYDQ]

Hmm. https://wiki.osdev.org/UEFI points at a couple of toolchains, using GCC or LLVM. Certainly in the GCC case that almost certainly implies use of the standard linker even if there is some subsequent operation to prepare a final file, so even if this is not a "custom toolchain" per se it would be reasonable to expect OP to already be familiar with the linker syntax and- in particular- the scripts that drive it.

UEFI simply runs PE/COFF binaries. So everything that can generate PE/COFF can also be used to generate UEFI binaries.

Subject to writing custom initialisation code etc., FPC should be able to do the job. Or rather, OP should be able to do the job using FPC >:-)

Considering that TYDQ already extended FPC to compile UEFI binaries... (look at some of their other threads if you're interested)

Do you have the plan to just add the support of PE binaries in every architecture targets?

If there would be an assembler out there (e.g. GNU as or llvm) then this would be possible. Otherwise someone has to implement an internal assembler for the architecture in question so that the internal COFF output writer can be used. But that definitely won't be me, except maybe for aarch64.

I demanded your support for PE/COFF support in every target!

I'm assuming that this is some mistranslation, because if you think that you can demand anything from me, then you're definitely mistaken.

OK......