OSDev.org

Oh, quoting the EFI 1.10 spec, the full paragraph says this:

The UGA Protocol sections of this specification were developed in close consultation with
Microsoft as part of the Universal Graphics Adapter (UGA) initiative. Microsoft has made
significant contributions to the interface definitions presented here to ensure that they will work
well with video adapters supporting the Microsoft UGA specification. These efforts are gratefully
acknowledged.

And also,

The EFI Byte Code Virtual Machine sections (Chapter 19) of this specification were developed in
close consultation with Microsoft, LSI, Hewlett Packard, Compaq, and Phoenix Technologies. The
efforts of all contributors to these sections are gratefully acknowledged.

* Note to myself - fact check what you read on the internet. And don't lie either, as there are plenty of people ready to fact check you.

Also, the "EFI ESP spec" is really the FAT32 spec, which (obviously) was developed by Microsoft, indepenent of EFI, and the "EFI executable format" is really "PE", which was also developed independently of EFI.

Now, I will say that Intel would have made our lives easier if they chose ELF. But I don't think that's morally wrong.

nexos wrote:* Note to myself - fact check what you read on the internet. And don't lie either, as there are plenty of people ready to fact check you.

This is what you simply don't understand.

I want them to fact check everything, especially the things I say. That's why I always provide links to my sources. Please do! Not just on this forum, but always, everywhere!
And Microsoft was involved in EFI from the very beginning, that wasn't a lie at all.

Cheers,
bzt

nexos wrote: Now, I will say that Intel would have made our lives easier if they chose ELF. But I don't think that's morally wrong.

oh, come on! I understand - UNIX fanboying and all, but have you tried to get through "dynamic linking" mess of ELF? in those specs, scattered through processor specific and not so specific pieces, those broken pdfs from 90s?... that would be exactly what UEFI should have dealt with if they chose this dumbass format. because your loader is a dynamically loaded executable object - if it is position dependent, then they should use a format, providing a decent and easy to use mechanism for fixups, what PE does. or, it should be quazi-PIC with all the consequences. Just read that freaking 5 chapter of Sys V ABI and you quickly understand why Intel has done so goooooood, picking PE.

nullplan wrote: I do find it fair to say that UEFI was designed with MSVC in mind (that's why the binary format is PE and the calling conventions are the MS ones, as that is the only thing MSVC is capable of generating, at least to my knowledge), and that clang works is just a happy little accident. Without definitive data, this is merely speculation, of course, but you have also offered no counter argument.

no no no, his quote was this:

not banned yet bzt wrote: Correction: UEFI was written with purely MSVC in mind, not C in general

see, it's not about format chosen, function naming style etc. it's a statement, about UEFI was not made for the C programming language, but for some MSVC C, which bzt has in its rich imagination. and this was what made me reply the way I did, because that statement was ... "extreme bullshit", as named.
as or the format chosen, ABI etc - it has nothing to do with C, as you probably know. it's up to compilers what targets to support. if GCC doesn't want to provide a decent PE targetting, because of religious reasons, it doesn't make UEFI "made for MSVC only and not for C in mind". You wouldn't seriously tell, that if names in UEFI follow Windows style, it makes the spec "MSVC and not C", wouldn't you?

and now, finally, the interesting part.

PS. personally, just for the sake of completeness, I compiled my UEFI OS Loader with clang too. For ARM32 and ARM64[1]. And it worked. heck, I even compiled the code for RISCV64! Just need to finish my ELF->PE conversion utility to try it out! yep, clang can't make PE targets for RISCV.

I managed to write that simple ELF->PE converter and my loader worked on RV64 qemu virt machine! too bad, there is no GOP in uboot yet to show graphical cuteness, but it works as supposed. btw, nexos, writing this utility, I had to learn ELF internals a bit. again - Intel wouldn't make our lives easier, choosing ELF, trust me. I say opposite - mainstream compiler writers would make our lives easier if stopped being stubborn p\/ssies and made bare PE a first class target.

So, clang targetting bare metal ELF, generated a valid code for my UEFI loader. after I converted it into PE, it worked. so is it also just a "happy coincidence", nullplan? note, for ARM and ARM64, you may say, clang mimicked MSVC, but here, with RV64, it couldn't! so what "definitive data" you need yet for approving them as a "counter argument" to that absolutely clownish statement? if there was a need to counter argument that in the first place.

here, is my lil loader, showing signs of presence on RV64 recorded in a clumsy video. ^_^

zaval wrote:oh, come on! I understand - UNIX fanboying and all, but have you tried to get through "dynamic linking" mess of ELF?

I agree dynamic linking in ELF is ugly. I am not a Unix fanboy, I actually find the POSIX API rather ugly. I like PE a lot better then ELF, trust me. It would just make cross compiling on Linux a lot easier if ELF was used. ELF is more of an industry wide standard then PE, as PE is used by Windows, while ELF is used by Linux, SVR4, Solaris, BSDs, and so on. But in reality, with EDK2, it really doesn't matter.

I wasn't even trying to pick on you. just expressing my humble opinion on the subject. the thread, well if the author "wants" to learn, then he/she needs to learn, that's pretty much all about it.

zaval wrote:I wasn't even trying to pick on you. just expressing my humble opinion on the subject. the thread, well if the author "wants" to learn, then he/she needs to learn, that's pretty much all about it.

I understand, it's hard to see the authors intention behind a computer screen

Rukog wrote:Ok so I can give you my 2 cents since I am doing that rn.

Learning asm without knowledge of other languages is a pure nightmare, you would need to do the compiler job in addition of the software programming aspect (manage registers (not) used, stack, code/data alignment, label management ect)

Ive made the mistake a decade ago of writing in assembly with only assembly knowledge.

And the language I am talking about isn't C, because C will not help you making a better asm code, or just the basic but not enough for complex software as an OS.

The language I am referring is OOP language, C# was my first experience and I was surprised how improvement Ive done in my asm coding ability.

The basic example of how OOP knowledge is important, is the label management aka name mangling for compiler.

It's super important if you want to structure your code, because no compiler will help you in that, you have to do this job from scratch.

NASM do have a nice local label management, it's basic but it does a good job.

Also yes, never fall in the trap of writing macro that try to mimic HAL features, it will just disgust you of assembly.

This reminds me of recommendations to learn different languages because they will teach you different ways to think. Learning Forth certainly improved my asm code. This surprised me because learning C didn't. C might have helped if I'd thought about it a bit more deeply, but I don't find that easy.

eekee wrote:This reminds me of recommendations to learn different languages because they will teach you different ways to think. Learning Forth certainly improved my asm code. This surprised me because learning C didn't. C might have helped if I'd thought about it a bit more deeply, but I don't find that easy.

Seconded. In order to learn your own language, learn a foreign one. Works with natural and programming languages. I never knew how weird German was before learning English. And no, I still don't know any pattern by which we assign genders to nouns.

C is peculiar, though. I often find low-quality C code to be written in what is basically assembler, and I find that sad. Way too many people treat C like a macro assembler, and fail to use the higher levels of abstraction. When you have someone jump around in a complicated nest of "if"-statements, only to ultimately end up setting a variable to 1 or 0, because apparently he never heard of logical operators. When people write stack tracing code and do it by constantly casting pointers all over the place, because a chance to just define a stack frame type was missed. When people assign function results into variables, only to use that variable in another function call, and then let it go out of scope.

This stuff is irksome. It makes the code way longer than it needs to be, and it reads way more tediously, and all just because people couldn't get out of the ASM mindset when writing C. So this is one thing about C: It has abstractions, but you actually have to use them.

nullplan wrote:

eekee wrote:This reminds me of recommendations to learn different languages because they will teach you different ways to think. Learning Forth certainly improved my asm code. This surprised me because learning C didn't. C might have helped if I'd thought about it a bit more deeply, but I don't find that easy.

Seconded. In order to learn your own language, learn a foreign one. Works with natural and programming languages. I never knew how weird German was before learning English. And no, I still don't know any pattern by which we assign genders to nouns.

C is peculiar, though. I often find low-quality C code to be written in what is basically assembler, and I find that sad. Way too many people treat C like a macro assembler, and fail to use the higher levels of abstraction. When you have someone jump around in a complicated nest of "if"-statements, only to ultimately end up setting a variable to 1 or 0, because apparently he never heard of logical operators. When people write stack tracing code and do it by constantly casting pointers all over the place, because a chance to just define a stack frame type was missed. When people assign function results into variables, only to use that variable in another function call, and then let it go out of scope.

This stuff is irksome. It makes the code way longer than it needs to be, and it reads way more tediously, and all just because people couldn't get out of the ASM mindset when writing C. So this is one thing about C: It has abstractions, but you actually have to use them.

My take is that pretty much every language has abstractions or is an abstraction - even Assembly is doing it for binary code. I had a rather different introduction to coding - I started with QuickBASIC and then went straight to Assembly (and later C/C++ and Pascal). These abrupt jumps between levels definitely helped me find a way to generalize well enough that learning new languages became much easier. And knowing Assembly (and how compilers generate code) definitely helped me write better higher level code, as I can organize the code in order to get the most out of the compiler, helping it in the optimizations. That's also what I teach my students, that regardless of what level they plan on working in the long run, they should always understand how it works underneath, because there's a difference between knowing a language and getting the most out of it.