Prev: Super Basic 80x86 Assembly Homework Help
Next: Bootstrapping DOS boot disk
From: Keith Kanios on 27 Oct 2007 13:47
There is a slight logical flaw going on here in assuming that NASM is
the problem. Has anyone ever stopped to think that maybe nagoa+.inc
isn't designed all that well???

I've worked with nagoa+.inc before, and I've found it to be a pig of a
include file and a poor substitute for a real linker. Some like to use
it for direct PE processing or hackish DLL endeavors, but it is really
not worth it... and you lose out on being able to link with other
files.

Just because your car has a trailer hitch, doesn't mean you should be
towing a cruise ship ;)

From: Betov on 27 Oct 2007 14:36
Keith Kanios <keith(a)kanios.net> �crivait news:1193507237.003682.47790
@o3g2000hsb.googlegroups.com:

> There is a slight logical flaw going on here in assuming that NASM is
> the problem.

The most important logical flaws, here, are the ones in
your diseased head, when re-distributing NASM, without
the Sources, and without noticing the LGPL, under the
name of NASM32, in order to try to compete with the MASM32,
as illegaly redistributed by your good old Hutch brother.

Fix this, before fixing the OP bugs, small head. (And pull
your trowsers up, next time you will have to bend down).


Betov.

< http://rosasm.org >

From: Frank Kotler on 27 Oct 2007 18:26
Keith Kanios wrote:
> There is a slight logical flaw going on here in assuming that NASM is
> the problem. Has anyone ever stopped to think that maybe nagoa+.inc
> isn't designed all that well???

One could, of course, examine it and determine if this is true, or not.

> I've worked with nagoa+.inc before, and I've found it to be a pig of a
> include file and a poor substitute for a real linker. Some like to use
> it for direct PE processing or hackish DLL endeavors, but it is really
> not worth it... and you lose out on being able to link with other
> files.

True if you "%define ONLY_NASM". The example in question does not - uses
Alink.

> Just because your car has a trailer hitch, doesn't mean you should be
> towing a cruise ship ;)

I'm not sure what the analog to the trailer hitch is. Nasm's got plenty
of "towing capacity" - might have to downshift and go slow...

The Tasm version works. The Nasm version does not. Obviously, Nasm is
emitting "bad code". This could be a bug in Nasm. It could be that Nasm
is being *told* to emit bad code. I know which way *I'd* bet!

The use of nagoa+.inc, whether it's "efficient" or "correct" aside,
results in code that can't easily be evaluated by looking at it. For
example:

CONST ID_LBOX_EXPORTS, equ 102

Does the author of that code understand what code this generates? Not
only a jump to the very next instruction, but a near jump! Even used as
intended, it doesn't generate what I'd call "elegant" code. Betov
complained about putting data in the middle of the code segment and
jumping over it - a near jump, no less. I agree with him. I favor
"small", generally, but I'll accept the bloat of adding an .rdata
section, and putting my "write it in the middle of code" data *there*,
in preference to putting it smack dab in the middle of the .text section
and jumping over it, any day!

Well... that's just the particular beef that got me disgusted looking at
the code... If Volcano seriously wants to get a working Nasm version of
that code, the first thing I'd do is "de-macro-ize" it a little and put
the instructions right out in front of our face so we can pick at it. No
harm in including nagoa+.inc (or better) for the equates, but that code
looks to me like it was written by someone who used the macros without
really understanding 'em. I'd be willing to bet that's where the problem
lies.

Best,
Frank
From: Terence on 27 Oct 2007 18:27

I read at least two more postings after ths one, which have now
disappeared!!
What gives?
Editing?

From: Keith Kanios on 27 Oct 2007 18:39
On Oct 27, 5:26 pm, Frank Kotler <fbkot...(a)verizon.net> wrote:
>
> that code
> looks to me like it was written by someone who used the macros without
> really understanding 'em. I'd be willing to bet that's where the problem
> lies.
>

That was my point, entirely :)

As I've said before, I've used nagoa+.inc. It is actually one of the
things that fueled my desire to see NASM32 through, but as a more
solid and stable approach. Even the initial releases of NASM32 used
ALINK. So those who think that NASM32 is trying to compete with
MASM32, by any resemblance whatsoever... well... they now know the
cost of ignorance ;)

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Super Basic 80x86 Assembly Homework Help
Next: Bootstrapping DOS boot disk