From: Betov on
"Wolfgang Kern" <nowhere(a)> �crivait news:feb12h$4jh$3

> You, and Rene as well, can't tell at all how many coders use RosAsm ...
> The fact that you don't see any questions like "how to install" or
> "why wont this work" is not an indication for its population count.

Hazard is sometimes funny. Just yesterday, i was googling about
the name "RosAsm", and i found several users (having done something
real), that i never heard about.



< >

From: rhyde on
On Oct 7, 12:51 am, Evenbit <nbaker2...(a)> wrote:
> It got most of the way to this goal when very little else was
> available. FASM was yet to be born. HLA was not yet conceived.

Actually, HLA was announced *before* SpAsm was.
HLA was announced in CLAX (and this group, IIRC) in Oct 1999. SpAsm's
announcement came along sometime in 2000.
Just to set the record straight.

Randy Hyde

From: rhyde on
On Oct 6, 7:33 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote:
> <rh...(a)> wrote in message
> news:1191603388.936214.65240(a)
> > On Oct 5, 1:45 am, "Rod Pemberton" <do_not_h...(a)nowhere.cmm> wrote:
> > > Unfortunately, Herbert's great stuff is lost on the world because he
> doesn't
> > > embrace x86 syntax.
> > Exactly what is "x86 syntax"?
> Specifically, it's the syntax that Intel defined. Loosely, it's something
> that looks reasonably close to what Intel publishes, uses Intel's names for
> instructions, uses Intel's names for registers, etc.
> > > So is Randall's because of his failure to embrace the C
> > > syntax fully.
> > And if I did, you'd simply be complaining that it's lost on the world
> > because I don't embrace x86 syntax.
> Pick one. Not two.
> > > MASM's syntax, of course, is being rapidly expired by NASM's.
> > Why don't you provide proof of this?
> 1) HLA which, according to recent posts, uses FASM whose syntax is derived
> from NASM.

Maybe recent posts by Rene. Surely you don't believe what he has
And if you're going to talk about what happens *inside* HLA, which no
one ever sees, don't forget that HLA also produces MASM code and MASM
is still the most commonly-used back-end for HLA. This may change, but
that's irrelevant because your second comment -- FASM syntax is
derived from NASM -- is not true at all.

> 2) Linux, the second most prominent OS, which doesn't run MASM, and where
> many prefer NASM to GAS.

"Many" may prefer NASM to GAS", but in my experience the vast majority
of people doing assembly under Linux are using GAS.

> 3) alt.os.development and most OS development sites like and
> where people are developing OSes. NASM is the predominant
> assembler choice.

Okay, I wouldn't know. Let's accept this on it's face value. Exactly
*how many* people are developing OSes in assembly? Not a *huge*
number in the big picture, I'm afraid.

> 4) LCC, which now has at least a half dozen ports, most of which use NASM
> as a backend.
> (LCC, LCC-Win32, LCC-Linux32, Pelles C, RadiOS LCC, "LCC-Q3VM" for
> Quake3)

As for point one, I'm not counting intermediate code generation by
compilers here.
Oh, and please provide me the reference to Pelles C producing NASM
code for the back end. I was unaware of this, and given that Pelle now
has his own (roughly MASM compatible) assembler, I'd expect him to
switch to that if he isn't generating object-code directly (which I
thought LCC did).

> >
> That's quite a bit of proof, but I suspect that no matter how much I
> provide, that it's somehow insufficient for you to adjust your current
> paradigms...

You're absolutely right. You've not really provided proof that NASM
syntax is supplanting MASM.

Certainly NASM is *popular*, but it has a long ways to go before it
supplants MASM. And for that matter, what I have been seeing over the
past several years is that FASM has been supplanting NASM.
Randy Hyde

From: rhyde on
On Oct 7, 1:28 am, santosh <santosh....(a)> wrote:
> Rod Pemberton wrote:
> [debate about whether NASM is/was suitable as a back-end for HLA]
> I think Randall has mentioned on several occasions that NASM was not
> powerful enough for his HLA _when_ he was developing the latter, IIRC
> sometime during the mid-90s, when NASM was in it's infancy.
> IIRC he did agree that NASM, as it stands now, *is* good enough as a
> back-end to HLA. Why then he chose to bolt-in FASM is rather confusing.

No. What I've said is that a couple of the stumbling blocks (such as
automatic displacement optimization) have been solved, but I haven't
looked at NASM recently in order to verify that the other issues (such
as using equated symbols before they are defined) have been dealt with

There are several reasons for choosing FASM output:

1. FASM is *much* faster than NASM. This, of course, impacts the speed
of an HLA compilation.
2. At the time I needed a "freely distributable" assembler. FASM fit
the bill and FASM's syntax was closer to what HLA was emitting than
was NASM's, so it made more sense to use FASM.
3. FASM was under active development at the time, NASM was not.
4. Tomasz has provided excellent support for FASM. When I've needed
something, he's either modified the compiler or provided a macro that
satisfied my needs -- with NASM, I would have had to figure out the
code myself.

Though NASM seems to have had a recent resurgence in interest, for the
reasons I listed above I'd still go with FASM if I were making the
decision today.
Randy Hyde

From: rhyde on
On Oct 7, 6:21 am, Betov <be...(a)> wrote:
> santosh <santosh....(a)> écrivaitnews:fea5b9$tks$1(a)
> For you, maybe. If you ignore the fact that Master Pdf always was
> a leader of the Anti-Gpl Mouvement, you cannot understand. See,
> for example his absurd claims saying that PD is *more* than GPL,
> and try to understand what this means.

Note, Rene, that PD *is compatible* with the GPL. Your RosAsm public
license, however, is not. So exactly who is the one who is more "anti-
GPL", you or me?

Oh, and tell us your thoughts on the GPL V3 again. I'd love to hear
you claim that you're so "pro-GPL" on one hand, while trashing the GPL
v3 (as you've done in the past). How do you explain that dichotomy?
Randy Hyde

First  |  Prev  |  Next  |  Last
Pages: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc