For those who use NASM, we would appreciate testing the Latest Build in your programming environment/setup so we can attend to any more potential bugs and finally push out an official 2.0 release.
Thanks for your attention and support
![Smile :)](./images/smilies/icon_smile.gif)
Code: Select all
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
Code: Select all
val EQU 0x0123456789ABCDEF
DQ val
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:a test caseCode: Select all
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 bitsassembled with the (in this case obviously pointless) warning on the EQU line, but produced exactly the same binary as yasm (the expected result)Code: Select all
val EQU 0x0123456789ABCDEF
DQ val
Code: Select all
DQ 123
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:a test caseCode: Select all
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 bitsassembled with the (in this case obviously pointless) warning on the EQU line, but produced exactly the same binary as yasm (the expected result)Code: Select all
val EQU 0x0123456789ABCDEF
DQ val
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
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...
H. Peter Anvin wrote:1) Yes, he's complaining about the bogus warning here. I agree with him; it's broken.
2) We do, but overhauling NASM's handling of CPU feature sets (of which FPU is only one) is a fairly complex project. I have thought about this one a lot over the past six months, but I haven't had time for it (I've already spent way more time on NASM than I should.)
I would say it's something I really want to do, but not for 2.00. We
may want to add "387" and "487" as dummy options, though.
3) > NASM can't add the path of the input file name to
> > the include file path, because standard C doesn't
> > provide a way for extracting or obtaining the path
> > component of a file name. In fact, such a means
> > would be incompatible with certain OSs. (Thus it
> > is up to the user to provide a -I option, replicating
> > the path that is part of the input file name.)
> >
> > In this particular case, use -I src/ to make it work.
> >
We could do it by, in effect, maintaining a collection of known filename
syntaxes. Someone might very well have already done that already. But
yes, there is no portable way to do that.
Wether or not I was the first, glad I could help.SpooK wrote:So, to summarize. Point 1 will be fixed.
As I said, its a yasm feature. a quick search-and-replace would make that compatible with nasm, at the cost of an automatic bug check which it currently provides. (like, not using FPU code in kernel land)Point 2 we'll get to.
Well, the yasm manual statesPoint 3 is an issue with breaking standards and compatibility, so get used to doing things properly, instead.
so I was doing things the right way.The search path defaults to only including the directory in which the source file resides.
2. Change EM64T to Intel 64 in Defining CPU Dependencies section of documentation.
SpooK wrote:Point 1 from this thread about NASM 2.00rc1 was indeed addressed, along with 9 other issues, thanks to the increased feedback we have been getting. Many thanks to those who have volunteered their time to help test NASM
All of the fixes have been implemented in NASM 2.00rc2
Let the cycle begin again
H. Peter Anvin wrote:Keith Kanios wrote:http://www.osdev.org/phpBB2/viewtopic.p ... 058#111058Candy wrote wrote:Allow me to also vote for file working directory. If you cannot rely on having the same compilation environment no matter from where the program is being executed (IE - cwd independant except for finding the directly referenced files) your program cannot be used properly in adjustable makefiles or similar systems.
Anything official you want me to relay in response to the above???
NASM behaves the way most compilers (e.g. just about every C compiler) does in this respect. The way to deal with that in Makefiles is to use -I to point to your include directory.
-hpa
SpooK wrote:Forewarning: Some cross quoting between this thread and the DEV group.H. Peter Anvin wrote:Keith Kanios wrote:http://www.osdev.org/phpBB2/viewtopic.p ... 058#111058Candy wrote wrote:Allow me to also vote for file working directory. If you cannot rely on having the same compilation environment no matter from where the program is being executed (IE - cwd independant except for finding the directly referenced files) your program cannot be used properly in adjustable makefiles or similar systems.
Anything official you want me to relay in response to the above???
NASM behaves the way most compilers (e.g. just about every C compiler) does in this respect. The way to deal with that in Makefiles is to use -I to point to your include directory.
-hpa
That's the official answer.