Why do we still bother?

I just got a bunch of "Yasm is so wonderful, and it
already has Macho64 
and AVX implemented" messages, and it's really starting
to make me feel 
that the time we've plowed into NASM was a huge waste of
time.

Do we really have any particular reason to not just say
"bugger it all 
to hell" and go home?

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

On Thursday 24 April 2008, H. Peter Anvin wrote:
> I just got a bunch of "Yasm is so wonderful, and
it already has Macho64
> and AVX implemented" messages, and it's really
starting to make me feel
> that the time we've plowed into NASM was a huge waste
of time.
>
> Do we really have any particular reason to not just say
"bugger it all
> to hell" and go home?

i'd agree on the pointlessness of maintaining two code
bases.  hindsight is 
wonderful, and yasm was able to review some of the design
shortcomings of 
nasm and so address it early on to remain scalable.  merging
the two projects 
would sound simply grand .

we (Gentoo) spent some time going through all the projects
that use nasm and 
tried to build them with yasm to see where yasm's
nasm-compatible layer wasnt 
doing things quite right, and so now the latest yasm release
should be usable 
for pretty much everything out there (off the top of my
head, command line 
options will remain broken in some cases ... nasm was lazy
and accepted case 
insensitive option flags in many cases even though it only
documented the 
upper case version).
-mike

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

On Thu, 24 Apr 2008 10:44:25 -0700
"H. Peter Anvin" <hpazytor.com> wrote:

> Do we really have any particular reason to not just say
"bugger it
> all to hell" and go home?

Personally, I would only feel that my time had been wasted
if we did
abandon the project -- which I have no intention of doing.

-- 
Chuck 
htt
p://www.pacificsites.com/~ccrayne/charles.html


------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Mike Frysinger wrote:
> On Thursday 24 April 2008, H. Peter Anvin wrote:
>   
>> I just got a bunch of "Yasm is so wonderful,
and it already has Macho64
>> and AVX implemented" messages, and it's really
starting to make me feel
>> that the time we've plowed into NASM was a huge
waste of time.
>>
>> Do we really have any particular reason to not just
say "bugger it all
>> to hell" and go home?
>>     
>
> i'd agree on the pointlessness of maintaining two code
bases.  hindsight is 
> wonderful, and yasm was able to review some of the
design shortcomings of 
> nasm and so address it early on to remain scalable. 
merging the two projects 
> would sound simply grand .
>
> we (Gentoo) spent some time going through all the
projects that use nasm and 
> tried to build them with yasm to see where yasm's
nasm-compatible layer wasnt 
> doing things quite right, and so now the latest yasm
release should be usable 
> for pretty much everything out there (off the top of my
head, command line 
> options will remain broken in some cases ... nasm was
lazy and accepted case 
> insensitive option flags in many cases even though it
only documented the 
> upper case version).
> -mike
>   
>
------------------------------------------------------------
------------

On the same note, our 64-bit development efforts have
brought out flaws 
in YASM, as well as diStorm64. I would also like to think
that HPA's 
efforts in ensuring a better relative addressing
representation makes a 
world of difference.

One thing I do like better about YASM, is the license... as
I am not 
much of a GPL zealot. However, in the case of NASM, the LGPL
is 
reasonable enough.

I also like the fact that NASM is
"battle-hardened" where-as YASM is 
still on training wheels, respectively.

I know I haven't been active lately (since December), but I
have no 
intention of abandoning NASM as long as the project focus
and direction 
isn't lost.

-Keith

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel