Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

FASM lacks OMF/OBJ support (16- / 32-bit) (Announce)

posted by Rugxulo Homepage, Usono, 02.01.2009, 19:59

> Does it really help ??? How do you use it to get 16-bit OMF from FASM ?

Oops, forgot about that. Okay, so it doesn't help there. But I think Tomasz's original viewpoint saw direct creation of .COM and .EXE as superior than requiring tons of external libraries. Then again, I also think he focused more on 386+ than 16-bit. It's not that 386 is so evil, just that people require 386 (or 486, 586, 686, etc.) for no good reason.

And sure a portable program in C is great, but sometimes portability is overrated (esp. if all you're running it on is one architecture). Or maybe it's just that C compilers still aren't as good as they should be (e.g. too slow to compile). Ironic that C is supposed to speed up development vs. assembly and yet takes a billion times longer to compile. Also, C is hardly portable (or maybe just really really hard to write truly portably, e.g. 64-bit clean, 16-bit ints, big endian, compiler quirks, etc.) A portable but slow, kludgy program is less admired than a decent non-portable x86-only one. (But obviously JWasm isn't bad, it's quite nice.) One of the reason TASM was so popular was its speed (although later versions of MASM were fast too, right?). OPTASM was supposedly pretty fast too, as was A86 (self-assembled). It's no accident that C-written assemblers are usually slower, we just don't notice these days due to fast computers. (Japheth, if you have any simple benchmarks, I'll try 'em on my 486 for you, heh.)

> Quality of OW suffered several times from bugs in the tools which were
> used to create the final release. So it is an additional risk.

And yet almost every compiler maker likes to brag that it compiles itself. The risk of hidden bugs never stopped any of them, that's for sure: GCC, FPC, FBC, GNAT, Context, CC386, various old DOS assemblers, etc. (contrary to G++ and GPC, which are written in C).

> most Real Mode DOS programs don't even need the MZ format. .COM (created
> by any good assembler's bin format) is fine for any program file below
> ~65280 Bytes

Most compilers don't output flat binary or .COM format, e.g. DJGPP or CC386 or whatever. And face it, most people use C or C++ or Pascal instead of assembly. And compilers are notorious for not making tiny code. It used to be that tiny code meant fast too but no longer. Also, 16-bit memory models were annoying to some / most, so they eagerly jumped onto the flat 32-bit model when it was introduced. 16-bit pmode of the 286 maxed out at 16 MB, which is better than 8086's not-quite 1 MB. And I don't think 99% of programmers ever desired to code in 16-bit pmode, esp. since 286s couldn't even (easily? officially? documented?) switch back to real mode, e.g. killing compatibility (only fixed in V86 w/ 386). Even in 1994, 486 computers sometimes only came with about 4 MB of RAM. 32-bit is considered easier than 16-bit in some ways (better addressing mode, bigger regs, bigger total address space).

Hope that made sense, it seems almost like an unfocused rant (must be tired, heh). :-P

 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 367 users online (0 registered, 367 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum