Unified Extensible Firmware Interface (UEFI) Example

[KradMoonRa]

Confirmed it's working, successfully builds UASM_uefi hello example.

AW thanks for pointing that the proposed version has other problems. I have dig in the code and found that the macros has serious problems, and like the convention aren't applied in prototypes by default. Fixed and cleaned up.

In assembly code the new adopted names can conflict and flagged has symbol redefinition.

Code Select Expand


IFNDEF INT8
INT8       TYPEDEF BYTE
ENDIF
IFNDEF UINT8
UINT8      TYPEDEF BYTE
ENDIF
IFNDEF INT16
INT16      TYPEDEF WORD
ENDIF
IFNDEF UINT16
UINT16     TYPEDEF WORD
ENDIF
IFNDEF INT32
INT32      TYPEDEF DWORD
ENDIF
IFNDEF UINT32
UINT32     TYPEDEF DWORD
ENDIF
IFNDEF INT64
INT64      TYPEDEF QWORD
ENDIF
IFNDEF UINT64
UINT64     TYPEDEF QWORD
ENDIF

;in C:\masm32\macros\macros.asm
IFNDEF memalign
      memalign MACRO reg, number
        add reg, number - 1
        and reg, -number
      ENDM
ENDIF



[jj2007]

You found a workaround, KradMoonRa

But having to edit standard Masm32 files is a major nuisance. Habran & Johnsa, please correct this name conflict.

Code Select Expand

;in C:\masm32\macros\macros.asm
IFNDEF memalign
      memalign MACRO reg, number
        add reg, number - 1
        and reg, -number
      ENDM
ENDIF

[aw27]

The supplied distributions, I have only tested the 64-bit one, work for the hello.asm sample. Any other solution, other than the KradMoonRa's, that would not write to the  CONST section was going to work as well as has been seen before.
However, the binary does not fix the bug mentioned here which is of a different nature. It does not fix as well the Masm32 incompatibility mentioned here (which was later rediscovered by JJ while assembling his fat Basic sources).

[TimoVJL]

The Windows 10 x64 mystery wasn't solved, more code just hides it.

PS: this should work too:
global.h

Code Select Expand

/* global strings for arch:sse/avx instructions to use */
extern char *MOVE_ALIGNED_FLOAT;
extern char *MOVE_ALIGNED_INT;
extern char *MOVE_UNALIGNED_FLOAT;
extern char *MOVE_UNALIGNED_INT;
extern char *MOVE_SINGLE;
extern char *MOVE_DOUBLE;
extern char *MOVE_SIMD_DWORD;
extern char *MOVE_SIMD_QWORD;
assemble.c

Code Select Expand

/* ARCH SSE/AVX specific instructions */
char *MOVE_ALIGNED_FLOAT; // = "movaps";
char *MOVE_ALIGNED_INT; // = "movdqa";
char *MOVE_UNALIGNED_FLOAT; // = "movups";
char *MOVE_UNALIGNED_INT; // = "movdqu";
char *MOVE_SINGLE; // = "movss";
char *MOVE_DOUBLE; // = "movsd";
char *MOVE_SIMD_DWORD; // = "movd";
char *MOVE_SIMD_QWORD; // = "movq";
option.c

Code Select Expand

if (tokenarray[i].token == T_ID) {
if (0 == _stricmp(tokenarray[i].string_ptr, "SSE")) {
MODULEARCH = ARCH_SSE;
ModuleInfo.arch = ARCH_SSE;
MOVE_ALIGNED_FLOAT = "movaps";
MOVE_ALIGNED_INT = "movdqa";
MOVE_UNALIGNED_FLOAT = "movups";
MOVE_UNALIGNED_INT = "movdqu";
MOVE_SINGLE = "movss";
MOVE_DOUBLE = "movsd";
MOVE_SIMD_DWORD = "movd";
MOVE_SIMD_QWORD = "movq";
archSym->value = ARCH_SSE;
}
else if (0 == _stricmp(tokenarray[i].string_ptr, "AVX")) {
MODULEARCH = ARCH_AVX;
ModuleInfo.arch = ARCH_AVX;
MOVE_ALIGNED_FLOAT = "vmovaps";
MOVE_ALIGNED_INT = "vmovdqa";
MOVE_UNALIGNED_FLOAT = "vmovups";
MOVE_UNALIGNED_INT = "vmovdqu";
MOVE_SINGLE = "vmovss";
MOVE_DOUBLE = "vmovsd";
MOVE_SIMD_DWORD = "vmovd";
MOVE_SIMD_QWORD = "vmovq";
archSym->value = ARCH_AVX;
}
those pointers are set for SSE / AVX only when needed.

[jj2007]

memalign is a built-in macro, did that source compile before ?

Yes. Now even the simplest Masm32 hello world chokes. You have a name conflict, please change the name of the built-in macro.

Btw this is another proof that built-in macros are a problem rather than a feature: The Masm32 memalign in macros.asm works just fine. MASM uses things like @InStr() and @CatStr() for its handful of built-in macros, maybe @MemAlign would be an option?

Code Select Expand

include \masm32\include\masm32rt.inc ; plain Masm32 for the fans of pure assembler

.code
AppName db "Masm32:", 0

start: MsgBox 0, "Hello World, how are you?", addr AppName, MB_OK
exit

end start

[hutch--]

I have seen this problem before long ago, when you have a MACRO assembler, you can extend it in many ways by using the pre-processor and doing simple macros like memory alignment is one of the more trivial tasks but it also means that the assembler does not have to try and emulate simple things that its pre-processor can routinely do.

Years ago Betov, the author of SpAsm tried to ape some of the routine masm macros but without a decent pre-processor, it flopped. Only Guga is brave enough to try and solve Betov's design problems. To each their design philosophy but if an assembler is to be MASM compatible, it will not exclude the basic MASM pre-processor capacity.

What I would suggest is abandon emulating MASM macros and if anything needs to be improved, fix the pre-processor so it is more consistent than the old MASM version. There is no reason why UASM cannot have its own set of macros which can be modified, added to or replaced, then it will be a properly extendable tool. Going down the path of trying to emulate a C compiler is a mistake, there are plenty of competent C compilers already.

[TimoVJL]

maybe an option switch for every additional features.

[aw27]

Independently of the arguments presented, which are pertinent as well, something I don't understand is the reason the MEMALIGN macro that exists in UASM for so many years only now is causing issues. Why is UASM considering "memalign" (which is the Masm32 version) the same as "MEMALIGN" (the UASM version)?

[TimoVJL]

macrolib.c line 170
AddLineQueue("memalign EQU MEMALIGN");

[jj2007]

maybe an option switch for every additional features.

Right - and "on" should not be the default. Even when the features are "on", they should not break the entirety of the accumulated Masm32 sources imho.

AsmC has a similar problem: many sources won't run without the /Zne option to disable non-Masm extensions. The whole point of compatibility is that 90% of all sources have been written for MASM. If you need to explain to a coder that in order to use the xyz assembler you need to teach your IDE to use the xyz command line options, you've lost that compatibility game, fullstop.

I had flagged the memalign issue in another thread but the post is no longer there

[aw27]

macrolib.c line 170
AddLineQueue("memalign EQU MEMALIGN");

Yeah, UASM is doing this for a selected and small number of macros, but the only one that appears to collide with Masm32 is the memalign. 
Some people here are confusing Masm with Masm32, Masm32 is an add-on SDK not developed and not endorsed by Microsoft.

[johnsa]

In this last release I added a case insensitive equ for memalign, which is why it is now colliding with the masm32 lib version.

I'm happy to remove the case sensitive version for this or rename it.. we can take a vote.
Personally I'd opt to rename it so that the case can be freely applied.

[KradMoonRa]

The internal macro library can be shut off by: -nomlib              Disable internal Macro Library
OR.
Can be selected all conflicting names and integrated separate -useadvmlib to use the new macro names, and still use the macros no conflicting.

using something like
.asm
options:nomlib  ;shutoff all macrolib inclusive the new ones
;or and
otions:useadvmlib ;use the new included macros

[jj2007]

Personally I'd opt to rename it so that the case can be freely applied.

I'd vote to name internal macros MASM style, like @CatStr(), @Instr(), so @MemAlign would be most consistent.

UASM is doing this for a selected and small number of macros, but the only one that appears to collide with Masm32 is the memalign

Indeed. I wonder why memalign chokes while fld FP8(2.0) doesn't

There is another little problem:

Code Select Expand

include \masm32\include\masm32rt.inc ; plain Masm32 for the fans of pure assembler
.586
.xmm
.code
AppName db "Masm32:", 0

start: MsgBox 0, "Hello World, how are you?", addr AppName, MB_OK
fld FP8(2.0)
Movss xmm0, FP4(2.3)
exit

end start

Fine for ML 6.14 but UAsm chokes with Error A2030: Instruction or register not accepted in current CPU mode

Some people here are confusing Masm with Masm32, Masm32 is an add-on SDK not developed and not endorsed by Microsoft.

Absolutely nobody would use MASM nowadays, had there not been the Masm32 SDK. It is the de facto standard for doing anything useful in assembly, at least for 32-bit code. And breaking its huge codebase is not a good idea.

[aw27]

Absolutely nobody would use MASM nowadays, had there not been the Masm32 SDK. It is the de facto standard for doing anything useful in assembly, at least for 32-bit code. And breaking its huge codebase is not a good idea.

Actually MASM is taught in college and high-school and Masm32 is not allowed there. Device Driver developers sometimes use Masm, and obviously can't use Masm32 for device drivers.
Very few people use Masm32, even here most people is more concerned with lateral matters than any sort of programming.
But Masm32 is a very valuable SDK, both 32-bit and 64-bit.