Of all the gin joints in all the towns in all the world, Stephen Polkowski had to walk into mine at 10:26:19 on Wednesday 19 February 2014 and say:
> Thanks for the reply Andrew! > > I admit there are but a few reasons to program without > "C". I can think of two. For example, educators might want to offer a > course in assembly language programming to their students. An other reason > would be to build an embedded OS without using the EDK2. No offense, but > the EDK2 is a configuration mess and way too complicated for a college > freshman. It would be way easier to give them one header file "uefi.inc" > with some structures and a template block of code. > > Anyhow, I guess I'll take a look at the Linux UEFI Stub. Somehow, they > figured out how to boot linux in UEFI without using the EDK2 build > environment. There exists a thing called GNU EFI (http://sourceforge.net/projects/gnu- efi/). It's a package which allows you to create EFI applications using a GCC that's targeted for ELF (you still need a binutils that understands the pei- i386 and pei-x86-64, but most systems support that by default these days). It's much smaller than EDKII, but it's based on the EFI 1.1 development environment and can't be used to create a complete firmware implementation for a given platform. It is handy if you just want to create an OS loader app though. -Bill > Regards, > > Stephen > > Andrew Fish wrote: > > On Feb 19, 2014, at 8:36 AM, Stephen Polkowski <step...@centtech.com > > > > <mailto:step...@centtech.com>> wrote: > >> Hi all, > >> > >> Does the EDK2 have a assembler only example of doing > >> a simple "Hello World" app? I would like a GNU GAS example, > >> but any would do. > > > > No. The BaseLib has assembler (and inline assembler) > > examples: > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/BaseLib/ > > > >> If there isn't an example, shouldn't the EDK2 have one? > >> I need to write an embedded OS that isn't tied to he EDK2 > >> build environment. > > > > The point of the BaseLib is to write code in C. So no there is not an > > assembly example. It is trivial. > > > > // typedef > > // EFI_STATUS > > // (EFIAPI *EFI_IMAGE_ENTRY_POINT) ( > > // IN EFI_HANDLE ImageHandle, // RCX > > // IN EFI_SYSTEM_TABLE *SystemTable // RDX > > // ); > > // > > // VOID > > // SetupEfi ( > > // IN EFI_HANDLE ImageHandle, > > // IN EFI_SYSTEM_TABLE *SystemTable > > // ); > > // > > > > .globl __ModuleEntryPoint: > > > > __ModuleEntryPoint: > > pushq %rbp > > > > movq %rsp, %rbp // Not required, but it makes debuggers happy > > > > callq _SetupEfi // Call C library constructor for EFI. > > > > // Do your thing > > movabsq $0, %rax // return EFI_SUCCESS > > popq %rbp > > > > ret > > > > So in this example you write all things EFI in C, like a sensible > > person. SetupEfi() can set globals like gBS, gRT, and gST, and you can > > call C code to do things EFI. > > > > Assuming you are generating the correct calling conventions 'clang -S > > -Os’ is your friend (works with gcc too). > > > > You could write the entry point in C and call the assembly too. Don’t > > know why you would write it all in assembly, especially since doing the > > pointer math on C structures is not going to be fun. > > > > Well I guess you could be using a different calling convention. > > > > Thanks, > > > > Andrew Fish > > > > PS If you are using a different calling convention look > > at: > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/Unix/Host/X64 > > /Gasket.S > > > > The emulator application uses Unix calling conventions while the EFI > > modules use EFI ABI: > > ReverseGasket* == Unix ABI code calling EFI ABI code > > Gasket* == EFI ABI Code calling Unix ABI code > > > >> Thanks, > >> > >> Stephen > >> > >> > >> > >> > >> > >> ------------------------------------------------------------------------ > >> ------ Managing the Performance of Cloud-Based Applications > >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > >> Read the Whitepaper. > >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.cl > >> ktrk > >> <http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg. > >> clktrk> _______________________________________________ > >> edk2-devel mailing list > >> edk2-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > ----- Managing the Performance of Cloud-Based Applications > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clk > > trk > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
