Website and stuff...

hpa wrote:
> I think I have access to that stuff.  It's very clear
we need someone 
> who actually doesn't mind doing web work doing that
stuff, so if there 
> is consensus I wouldn't mind adding Keith as whatever
he needs to be 
> do help us with the web pages.
>
> I think NASM is in a bit of disarray at the moment,
given the sheer 
> amount of work that it'd need to support 64-bit code. 
We were hoping 
> that YASM was going to fill that role, but even the
latest YASM can't 
> handle existing 32-bit NASM code.
>
>     -hpa

Well, I was discussing with Frank that the smart money would
be for YASM 
to collapse into NASM and combine forces, in terms of
decreasing 
development time. YASM will continue to suffer from name
recognition, or 
the lack-there-of. NASM will, seemingly, continue to suffer
from 
development stagnation. In this respect, combining forces
seems like a 
win-win situation. This, of course, ignores the obvious
(L)GPL vs. BSD 
license issue and potential ego conflicts.

As for anything beyond the development-time factor, I just
wouldn't be 
interested in YASM, even if it does have 64-bit support. I
would 
actually rewrite NASM myself before I would exclusively use
YASM. I 
think the fact that YASM tries to be NASM+GAS takes away
from the focus 
of the assembler, and breaks into the realm of one
"good" tool instead 
of many "great" tools. I know most NASM users are
*nix types so they 
naturally understand the power of that last statement.

The *biggest* issue I see for NASM itself is the fact that
the 
instruction set is statically multiplexed, and soon you will
run out of 
room in the instruction set flag. Personally, I would change
to dynamic 
recompilation of the instruction set. After this happens,
though I am 
not saying it will be easy, I don't see much more of a rough
road for 
NASM development as long as the tradition of volunteers
continues.

At any rate, I will get on bringing the website up-to speed
as soon as I 
have (and find out that I have) access. I will be gone for a
few hours 
from the time of this posting, so you have to excuse that
time-frame. 
Please let me know what the decision is 

PS: What is the legality of NASM >0.98.25 being forked
with the LGPL 
instead of the existing NASM license??? I am not trying to
stir 
emotions/conflict, I am just curious as to the
interpretation of the 
NASM license that authorizes such an action, if not done by
the original 
authors.

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

H. Peter Anvin wrote:
> Keith wrote:
>>
>> The *biggest* issue I see for NASM itself is the
fact that the 
>> instruction set is statically multiplexed, and soon
you will run out 
>> of room in the instruction set flag. Personally, I
would change to 
>> dynamic recompilation of the instruction set. After
this happens, 
>> though I am not saying it will be easy, I don't see
much more of a 
>> rough road for NASM development as long as the
tradition of 
>> volunteers continues.
>>
>
> No, I think the biggest issue is that all the datatypes
in NASM needs 
> to be revved from using stuff like "unsigned
long" to using 
> [u]int{16,32,64}_t, in order to have a prayer of
supporting 64-bit mode.
Well, just another thing that needs to be done. If no one
seems to be 
willing to do the grunt work, don't worry, that is something
I am quite 
used to ;)

>> At any rate, I will get on bringing the website
up-to speed as soon 
>> as I have (and find out that I have) access. I will
be gone for a few 
>> hours from the time of this posting, so you have to
excuse that 
>> time-frame. Please let me know what the decision is

>>
>> PS: What is the legality of NASM >0.98.25 being
forked with the LGPL 
>> instead of the existing NASM license??? I am not
trying to stir 
>> emotions/conflict, I am just curious as to the
interpretation of the 
>> NASM license that authorizes such an action, if not
done by the 
>> original authors.
>>
>
> The change was authorized by the original authors, so
it's not an issue.
>
>     -hpa
>

Fair enough 

BTW: My sourceforge username is "kkanios" 
(http://sourcefo
rge.net/users/kkanios/) in-case you need to add me to 
anything 

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

> The *biggest* issue I see for NASM itself is the fact
that the 
> instruction set is statically multiplexed, and soon you
will run
> out of room in the instruction set flag.

I disagree, i.e. I don't see that as the biggest issue.
(Fwiw, I
did have to widen them from 32 to 64 bits for NASM64, and,
after
running out once more, widen them again to 2x 64 bits.)

> PS: What is the legality of NASM >0.98.25 being
forked with the LGPL 
> instead of the existing NASM license???

NASM 0.98p9 was the last NASM under the original proprietary
li-
cense, extended by a clause that also allowed distribution
under
the GPL. In April of 2002 the public version of NASM
switched to
the LGPL. So, depending on where you "fork" from,
you can end up
with the original proprietary license, the GPL, or the
LGPL.


 
____________________________________________________________
________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
htt
p://farechase.yahoo.com/promo-generic-14795097

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Keith wrote:
> hpa wrote:

Hmmm... why am I not seeing the original, but only this
reply? (does 
that Gnu look sober to you?) Well, reply to the reply...

>>I think I have access to that stuff.  It's very
clear we need someone 
>>who actually doesn't mind doing web work doing that
stuff, so if there 
>>is consensus I wouldn't mind adding Keith as
whatever he needs to be 
>>do help us with the web pages.

Well, I vote for Keith, and two votes is apt to be a
"landslide" around 
here, so I've added Keith as a "developer" with
"permissions" here an 
there... (or tried to). Try it out Keith, and if you need
"more" we'll 
work on it.

>>I think NASM is in a bit of disarray at the moment,
given the sheer 
>>amount of work that it'd need to support 64-bit
code.  We were hoping 
>>that YASM was going to fill that role, but even the
latest YASM can't 
>>handle existing 32-bit NASM code.

Really? Bummer! I haven't kept up with Yasm at all, despite
my intention 
to do so.

...
> As for anything beyond the development-time factor, I
just wouldn't be 
> interested in YASM, even if it does have 64-bit
support. I would 
> actually rewrite NASM myself before I would exclusively
use YASM. I 
> think the fact that YASM tries to be NASM+GAS takes
away from the focus 
> of the assembler,

Really? That seems to me to be a "good thing"
about Yasm - "even 
Netwider than Nasm", or whatever...

> and breaks into the realm of one "good" tool
instead 
> of many "great" tools. I know most NASM users
are *nix types so they 
> naturally understand the power of that last statement.

That's a good point.

> The *biggest* issue I see for NASM itself is the fact
that the 
> instruction set is statically multiplexed,

Okay. Taking a somewhat shorter-range view, I'd say rhe
"biggest" issue 
right now is that "-O2" and "-O3" are
broken... Whatever...

Best,
Frank


------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel