NASM 2.00rc1

[SpooK]

NASM has now approached release candidate status. All major bugs on the path to adding x64 support have been squashed.

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

[XCHG]

Spook,

I can not access FTP in University's residences. I would appreciate it if you could, please, post a link to images served on HTTP.

[Combuster]

I tried porting my kernel from yasm to nasm, but it gave three different sets of issues. First I'm flooded with this:

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

a test case

Code: Select all

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)


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


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...

[XCHG]

I tried porting my kernel from yasm to nasm, but it gave three different sets of issues. First I'm flooded with this:

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

a test case

Code: Select all

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)

NASM, from what I know, using the 32-Bit mode, treats DD as DWORD and DQ as a 64-bit Floating point not an integral fixed point value. So:

Code: Select all

DQ      123

Is not acceptable by NASM (at least in the version that I am using). I always find it really difficult to deal with 64-bit QWORD values in NASM for this reason. I remember that TASM Version 3.2 (16-bit) was able to deal with 64-bit QWORD values using the DQ and with 80-bit TBYTE values with the DT keywords. I wish these were also supported in NASM.

[SpooK]

I tried porting my kernel from yasm to nasm, but it gave three different sets of issues. First I'm flooded with this:

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

a test case

Code: Select all

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.

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.

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

[SpooK]

Here is the responses from the DEV list, in respect to Combuster's points. The response to point 3 is also a comment/response by/to someone else in the DEV list.

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.

So, to summarize. Point 1 will be fixed. Point 2 we'll get to. Point 3 is an issue with breaking standards and compatibility, so get used to doing things properly, instead.

[Frank Kotler]

XCHG,

Like, drop out, maaaan! Go to a school that *does* let you ftp!

We just got 2.00rc1 up on SourceForge, so you should be all set.

http://sourceforge.net/project/showfile ... up_id=6208

On the other issues... I would point out that compatibility with Yasm has never been a design goal for Nasm. On the contrary. That said, we'll *try* to maintain compatibilty with Yasm... but it's not a "Nasm problem".

My understanding is that Nasm *is* supposed to accept a 64-bit integer as an argument to "dq" (unlike previous versions which accepted *only* a double-precision float). Watch for "rc2" on this one.

Nasm, at one point, *did* add a slash to the end of an "-I" (include path) parameter, if the user didn't supply either slash or backslash. This (mis)feature was removed, because it broke documented (as "perverse", but documented) behavior, which some people were apparently counting on. In general, I'd say do *not* expect Nasm to become "OS aware". It is deliberately ignorant... I mean "independent" of the OS it's running on.

Thanks to all for the feedback!

Best,
Frank

[Combuster]

So, to summarize. Point 1 will be fixed.

Wether or not I was the first, glad I could help.

Point 2 we'll get to.

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 3 is an issue with breaking standards and compatibility, so get used to doing things properly, instead.

Well, the yasm manual states

The search path defaults to only including the directory in which the source file resides.

so I was doing things the right way. That nasm happens to do it different is a design choice I wont argue about (your arguments are completely valid, and so are the arguments to do it the other way), but it does force me to make a choice between the two assemblers as I can not support both properly without making ugly sacrifices in the makefile script.

While I do think you are doing a good job, I hope you can understand my decision to stick with yasm.

[SpooK]

While I do think you are doing a good job, I hope you can understand my decision to stick with yasm.

Yep yep. Go with what you know... and thanks testing things out

[SpooK]

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

[Combuster]

Curious about the other issues, I found the following:

2. Change EM64T to Intel 64 in Defining CPU Dependencies section of documentation.

Intel 64 / IA64 = Itanium
(link)

[Candy]

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

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.

[SpooK]

Curious about the other issues, I found the following:

2. Change EM64T to Intel 64 in Defining CPU Dependencies section of documentation.

Intel 64 / IA64 = Itanium
(link)

IA-64 != Intel 64. Read THIS thread for more information as to why

[SpooK]

Forewarning: Some cross quoting between this thread and the DEV group.

http://www.osdev.org/phpBB2/viewtopic.p ... 058#111058

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.

[Candy]

Forewarning: Some cross quoting between this thread and the DEV group.

http://www.osdev.org/phpBB2/viewtopic.p ... 058#111058
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.

C offers the possibility of #include <> or #include "" for that very purpose. What about offering the same functionality, or if you don't see a way to do so, to offer only the second (which includes all of the first)?