Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

NASM version 2.09 available (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 03.09.2010, 14:40

> Well, it's a slippery slope. The only format that definitely can't be used
> in DOS (that I know of) is Mach-O. Everything else has weird hacks or
> libraries that can work (EMX or DJELF or BCC/Dev86).
Then users of the port would have to compile that on their own, excluding other output formats if necessary.

> I checked yesterday, the old 0.98.39 16-bit .EXE (I think) supported bin,
> obj, as86, and win32.
Thanks. AS86, AOUT, AOUTB and the Intel/Motorola hex formats would be definitively excluded too.

> 2.09's "wmake -f mkfiles\openwcom.mak dos" doesn't work as-is in pure DOS
> with DOS-hosted compiler due to cmdline limits (128 bytes? 126?).
Doesn't OpenWatcom know of CMDLINE= maybe?

> 486 and 586 are pretty minor, so they should also be included, IMHO, but
> everything beyond that is overkill.
Yeah.. maybe basic 686, but MMX contains lots of instructions. It could also save space to leave out the MMX register handling if I would find a way for that.

> Unpacked, the old 16-bit 0.98.39 .EXE is less than 250 kb, which should
> leave ample memory (famous last words) for reasonable projects.
That's what I'm concerned about. I don't think it's enough. My sources are up to 600 KiB per project, and I think NASM needs to store the complete tokenized source in memory. Even if it strips all the comments, that's still at least 200 KiB.

> (You could
> argue that they should be split into separate .OBJs anyways if bigger.)
No. Complicated section arrangement isn't possible with OMF .OBJ output format as easily as with NASM's bin output format. (Writing a kind of post-processor or specialized linker would make it easier, but I don't consider this an option since it's more work and complicates the build process.)

> I know, I just meant it generates smaller code (I think).
I don't think code size is much of an issue, most code appears to fit in one segment. Besides, wasn't Watcom one of the better compilers too?

> (so he could test on his 8088).
I have at least one 16-bit x86 emulators (i.e. it emulates only the 186 instruction set) so debugging would probably be done within that.

> > It could be optional, with disk swapping if no XMM is installed.
> Because,
> > you see, I did mention disk swapping and XMS.
>
> Ralf Brown's SPAWNO??
What? No. I consider myself able to write code which swaps data in and out of memory to XMS or a file as necessary. The hardest part would of course be to detect when to do that on what of NASM's data, but that's exactly the code I would have to write anyway if using someone else's XMS/file access code for NASM.

> (Don't forget EMS! Trixter's 8088 has 2 MB of real EMS!)
Good call.

> I personally never fell in love with all the HLL stuff that MASM, etc.
> added, but feel free to use whatever floats your boat!
Or bloats my foat? Hmmmm. No, really, most of the macros I use are for stuff like writing data (tables..), messages and exceptional code that can't be achieved unless using db (like for patching). Then there's some macros that deal with NASM command line parameters so I could define an option "TEST" and then either say nasm -D_TEST or (equivalent) nasm -D_TEST=1 or nasm -D_TEST=0. The macros automatically assign a default value to the single-line macro _TEST so that I can use it like %if _TEST && other_condition or as db '0'+ !!_TEST everywhere in the source, even if it wasn't defined on the command line. %ifdef is overrated.

My code, on the other hand, contains only few or no HLL-like macros known from other source code (IF, WHILE, etc) with the exception of debugging stuff; like d4bp which writes an int3 opcode only if the option DEBUG4 is enabled, and d4message "Blah Blub" which displays a message but like-wise only emits anything if the option is enabled.

> Dunno, doubt it, but LGPL ain't so horrible either. I just think "an
> assembler is an assembler", and "it's good enough" or whatever.
Yep, no practical reasons against it. For using it yourself, Copyleft ain't any worse.

> All the
> string and preprocessing stuff isn't as useful (to me personally).
*cough*automaticmessageandtablemaintenanceplusgeneration*cough*.

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22649 Postings in 2111 Threads, 402 registered users, 914 users online (1 registered, 913 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum