Combuster wrote:
I tried porting my kernel from yasm to nasm, but it gave three different sets of issues. First I'm flooded with this:
Code:
inc_ia.asm:44: warning: numeric constant 0x0000007fc0000000 does not fit in 32 bits
inc_ia.asm:45: warning: numeric constant 0x0000ff8000000000 does not fit in 32 bits
inc_kernel.asm:44: warning: numeric constant 0x4000000000000000 does not fit in 32 bits
inc_kernel.asm:45: warning: numeric constant 0x8000000000000000 does not fit in 32 bits
inc_kernel.asm:46: warning: numeric constant 0xC000000000000000 does not fit in 32 bits
a test case
Code:
val EQU 0x0123456789ABCDEF
DQ val
assembled with the (in this case obviously pointless) warning on the EQU line, but produced exactly the same binary as yasm (the expected result)
At first glance, I would actually have to agree with you. However, I have notified the DEV team of this, as I cannot honestly/fully answer this one ATM due to my personal workload.
Combuster wrote:
The second set of errors regards CPU arguments, which is probably a feature of yasm's, but nasm chokes whenever you feed it CPU xxxxx FPU
Yes, this is unique to YASM. I can see how "CPU 387" and "CPU 487" could be useful, but it is a rather insignificant "feature" since the majority of CPUs include the x87 FPU.
At any rate, the DEV team will see your message, but don't get your hopes up.
Combuster wrote:
The third is the most annoying problem since I can't easily fix it without having two different editions of the source files.
1) when a file is included, nasm will not look for that file in the directory where the main file is. (i.e. "nasm file.asm" works while "cd .." "nasm src/file.asm" does not)
2) I have to suffix a path with a trailing backslash to have nasm check in there (which cost me 10 minutes to figure out)
In all, I think I'll stick with yasm for now...
This is standard practice, to treat relative files from the standpoint of the current working directory. Imagine having "data.asm" in both directories... with different content
Proper use of NASM's "-I" argument is highly suggested for these situations.
Thanks for the feedback, Combuster. I will let you know what the DEV team decides on all of these points