Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
rr

Homepage E-mail

Berlin, Germany,
25.08.2010, 13:27
 

NASM version 2.09 available (Announce)

Post reply

The NASM developers have released NASM version 2.09 on 24 August 2010.

Home page: http://www.nasm.us/
Download: http://www.nasm.us/pub/nasm/releasebuilds/2.09/

Changes:
? Fixed assignment the magnitude of %rep counter. It is limited to 62 bits now.
? Fixed NULL dereference if argument of %strlen resolves to whitespace. For example if nonexistent macro parameter is used.
? %ifenv, %elifenv, %ifnenv, and %elifnenv directives introduced. See section 4.4.9.
? Fixed NULL dereference if environment variable is missed.
? Updates of new AVX v7 Intel instructions.
? PUSH imm32 is now officially documented.
? Fix for encoding the LFS, LGS and LSS in 64-bit mode.
? Fixes for compatibility with OpenWatcom compiler and DOS 8.3 file format limitation.
? Macros parameters range expansion introduced. See section 4.3.4.
? Backward compatibility on expanging of local sigle macros restored.
? 8 bit relocations for elf andbin output formats are introduced.
? Short intersegment jumps are permitted now.
? An alignment more than 64 bytes are allowed for win32, win64 output formats.
? SECTALIGN directive introduced. See section 4.11.13.
? nojmp option introduced in smartalign package. See section 5.2.
? Short aliases win, elf and macho for output formats are introduced. Each stands for win32, elf32 and macho32 accordingly.
? Faster handling of missing directives implemented.
? Various small improvements in documentation.
? No hang anymore if unable to open malloc.log file.
? The environments without vsnprintf function are able to build nasm again.
? AMD LWP instructions updated.
? Tighten EA checks. We warn a user if there overflow in EA addressing.
? Make -Ox the default optimization level. For the legacy behavior, specify -O0 explicitly. See section 2.1.22.
? Environment variables read with %! or tested with %ifenv can now contain non-identifier characters if surrounded by quotes. See section 4.10.2.
? Add a new standard macro package %use fp for floating-point convenience macros. See section 5.3.

---
Forum admin
DOS386

26.08.2010, 09:10

@ rr
 

NASM version 2.09 available

Post reply

> The NASM developers have released NASM version 2.09 on 24 August 2010
> Fixes for compatibility with OpenWatcom compiler and DOS 8.3 file format
So it compiles in DOS with Open WATCOM ? This looks like good news, although I personally don't have that big need to compile my NASM from source :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
26.08.2010, 20:10

@ DOS386
 

NASM version 2.09 available

Post reply

> So it compiles in DOS with Open WATCOM ? This looks like good news,
> although I personally don't have that big need to compile my NASM from
> source :-)
Don't know, but that's probably what they addressed there (they stripped down most source code file names to SFNs).

I today got it to compile for an 8086 DOS target after stripping the supported instruction set down to 686 - both executables (NASM and NDISASM) appear to work, but NASM.EXE is a 460 KiB file which means that it barely runs at all and usually crashes if I try to assemble anything at all (at least I hope the crash is only due to running out of memory). NDISASM.EXE works fine though, and is just about 110 KiB.

So NASM still can be compiled for 8086 systems. If I have time for that, I might look into stripping it down better to get the executable's size down. Maybe write some code to let it use disk or XMS swapping? Hmm.

---
l
DOS386

27.08.2010, 03:16

@ ecm
 

NASM version 2.09 available

Post reply

> that's probably what they addressed there (they stripped
> down most source code file names to SFNs)

:-)

> appear to work, but NASM.EXE is a 460 KiB file which means that it barely
> runs at all and usually crashes if I try to assemble anything at all
useless ...

> NDISASM.EXE works fine though, and is just about 110 KiB.
:-)

> So NASM still can be compiled for 8086 systems. If I have time for that, I
> might look into stripping it down better to get the executable's size down.
If you get something useful please announce and release it :hungry:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
marcov

27.08.2010, 17:10

@ ecm
 

NASM version 2.09 available

Post reply

> NASM.EXE is a 460 KiB file which means that it barely
> runs at all and usually crashes if I try to assemble anything at all (at
> least I hope the crash is only due to running out of memory). NDISASM.EXE
> works fine though, and is just about 110 KiB.
>
> So NASM still can be compiled for 8086 systems. If I have time for that, I
> might look into stripping it down better to get the executable's size down.
> Maybe write some code to let it use disk or XMS swapping? Hmm.
Maybe time to throw out those 8086's and 80186, and raise the limit to a more modern machine, like a 286 ? :-D :-D :-D
Rugxulo

Homepage

Usono,
28.08.2010, 04:53

@ marcov
 

NASM version 2.09 available

Post reply

> > NASM.EXE is a 460 KiB file which means that it barely
> > runs at all and usually crashes if I try to assemble anything at all (at
> > least I hope the crash is only due to running out of memory).
> NDISASM.EXE
> > works fine though, and is just about 110 KiB.
This is probably because of all output formats enabled by default. You'll have to manually disable non-DOS targets (win32, macho) in NASM.H or OUTPUT.H or whatever (I forget), which is what was typically done in old 0.97/0.98 days. Then it should run a little better (but not much). Last 16-bit build is for 0.98.39, found on SourceForge, which lacks x86-64 support which isn't needed here anyways. (Turbo C will produce smaller code, I think, but I may be thinking of after UPX, which wouldn't help shrink RAM use. Make sure to use -os or -oxs or whatever for OpenWatcom. EDIT: Oops, TC doesn't support C99, doh.)

> > So NASM still can be compiled for 8086 systems. If I have time for that,
> I
> > might look into stripping it down better to get the executable's size
> down.
> > Maybe write some code to let it use disk or XMS swapping? Hmm.
>
> Maybe time to throw out those 8086's and 80186, and raise the limit to a
> more modern machine, like a 286 ? :-D :-D :-D
Yes, if he's using XMS at all in the future, it will be 286+ only. I believe cm is using NASM 2.04+ features in his port of RxDOS. While I don't personally see a huge need to have a 16-bit NASM just to assemble that, it would still be cool to have. I guess he likes the new macro features or whatever.

---
Know your limits.h
ecm

Homepage E-mail

Düsseldorf, Germany,
30.08.2010, 21:40

@ Rugxulo
 

NASM version 2.09 available

Post reply

> This is probably because of all output formats enabled by default. You'll
> have to manually disable non-DOS targets (win32, macho) in NASM.H or
> OUTPUT.H or whatever (I forget), which is what was typically done in old
> 0.97/0.98 days. Then it should run a little better (but not much).
Already thought about that. I'll probably disable macho and elf (maybe rdf too), but win32 and coff might be useful for HX and DJGPP development. I'll also have to look into making these things optional via C preprocessor variables so that we might get these patches into the official NASM builds. That could be accomplished with an additional makefile for Open Watcom that only has 16-bit DOS as target. (The label dos is currently used for the DPMI output format in the Open Watcom makefile.)

> which lacks x86-64 support which isn't needed here anyways.
As I wrote, I already disabled post-686 instructions, including all IA64-emulation and AMD64 stuff. I'll look into disabling support for these architectures in other places except the expression evaluator (that would be too much work).

I thought about disabling post-386 instructions too. This way, one would be able to create basic 32-bit programs with the 16-bit build, but anything else would require the DJGPP build.

> Make sure to use -os or -oxs or whatever for OpenWatcom.
Yep, already done. I also tested other different options. I have to manually enter different data segment names to avoid overflowing the default segment. All the data needs to be handled as far too. (Large or Huge memory model.) Maybe Open Watcom can be talked into moving data to overlays, which may or may not enable segments or even single items larger than 64 KiB.

> EDIT: Oops, TC doesn't support C99, doh.
I really wasn't looking forward to extend my toolchain to the semi-free TC either. (You only get the binaries, and only from that one hidden museum site.)

> > Maybe time to throw out those 8086's and 80186, and raise the limit to a
> > more modern machine, like a 286 ? :-D :-D :-D
Actually, the oldest real machine I'm running has a 586-class CPU. Porting it to a 16-bit platform is just for fun.

> Yes, if he's using XMS at all in the future, it will be 286+ only.
It could be optional, with disk swapping if no XMM is installed. Because, you see, I did mention disk swapping and XMS.

> I guess he likes the new macro features or whatever.
Right. Besides, I'm usually with the latest daily build of NASM. Some of my code right now probably won't even assemble with 2.07, and I'm already planning to use the better preprocessor of the upcoming 2.10 release. 0.98.xx was a joke compared to what we get now. (Also, I don't know whether you are allowed to use 2.06 or older releases under the 2-clause BSD license. That's important to me for ideological reasons.)

---
l
Rugxulo

Homepage

Usono,
03.09.2010, 05:51

@ ecm
 

NASM version 2.09 available

Post reply

> Already thought about that. I'll probably disable macho and elf (maybe rdf
> too), but win32 and coff might be useful for HX and DJGPP development.

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).

I checked yesterday, the old 0.98.39 16-bit .EXE (I think) supported bin, obj, as86, and win32.

> That could be accomplished with an additional makefile for Open Watcom that
> only has 16-bit DOS as target. (The label dos is currently
> used for the DPMI output format in the Open Watcom makefile.)
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?).

> I thought about disabling post-386 instructions too. This way, one would be
> able to create basic 32-bit programs with the 16-bit build, but anything
> else would require the DJGPP build.
486 and 586 are pretty minor, so they should also be included, IMHO, but everything beyond that is overkill.

> Yep, already done. I also tested other different options. I have to
> manually enter different data segment names to avoid overflowing the
> default segment. All the data needs to be handled as far too. (Large
> or Huge memory model.) Maybe Open Watcom can be talked into moving
> data to overlays, which may or may not enable segments or even single items
> larger than 64 KiB.
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. (You could argue that they should be split into separate .OBJs anyways if bigger.)

> > EDIT: Oops, TC doesn't support C99, doh.
>
> I really wasn't looking forward to extend my toolchain to the semi-free TC
> either. (You only get the binaries, and only from that one hidden museum
> site.)
I know, I just meant it generates smaller code (I think).

> Actually, the oldest real machine I'm running has a 586-class CPU. Porting
> it to a 16-bit platform is just for fun.
Jim Leonard hasn't been as active as before, he hasn't responded to some basic e-mails, so maybe he's losing interest, else I'd suggest you e-mail him (so he could test on his 8088). Perhaps Mike Chambers would be interested??

> 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?? (Don't forget EMS! Trixter's 8088 has 2 MB of real EMS!)

> > I guess he likes the new macro features or whatever.
>
> 0.98.xx was a joke compared to what we get now.

I personally never fell in love with all the HLL stuff that MASM, etc. added, but feel free to use whatever floats your boat!

> (Also, I don't know whether
> you are allowed to use 2.06 or older releases under the 2-clause BSD
> license. That's important to me for ideological reasons.)
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. All the string and preprocessing stuff isn't as useful (to me personally).
Arjay

03.09.2010, 13:14
(edited by Arjay, 03.09.2010, 13:31)

@ Rugxulo
 

NASM version 2.09 available

Post reply

> The only format that definitely can't be used
> in DOS (that I know of) is Mach-O.
I spotted that a C++ (OSX) based Mach-O file viewer now exists on SourceForge
http://sourceforge.net/projects/machoview/ the project was registered on 15-July-2010.

> Jim Leonard hasn't been as active as before,
 From following his blog ( http://trixter.wordpress.com/ ) I noted a few months back that he started a busy new job. He has also been busy with Mind Candy 3.

> so maybe he's losing interest,
Lol, somehow I think that will only happen when hell freezes over ;)

> him (so he could test on his 8088).
FYI, presently I still own several 8086's, 80186's, 286 etc. Long term I'm considering my options with regards to donating to a museum or similar. You can't beat real hardware. Unfortunately at this present time I'm not setup to test stuff easily or to put it another way most of my kit is in storage and I simply I haven't had a chance to set myself up again with my multiple switch box etc. But I plan to have a test rack of some sorts again where I can literally quickly test stuff with a 8086, 80186, 286, 386 etc.
ecm

Homepage E-mail

Düsseldorf, Germany,
03.09.2010, 14:40

@ Rugxulo
 

NASM version 2.09 available

Post reply

> 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
DOS386

06.09.2010, 20:06

@ ecm
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> I believe cm is using NASM 2.04+ features in his port of
> RxDOS. While I don't personally see a huge need to have a
> 16-bit NASM just to assemble that, it would still be cool
An 8086 DOS kernel done in pure ASM and compilable on 8086 would be very COOL :-) Of course the assembler should compile from its source on 8086 and be done in pure ASM too. If done in C then it should compile on 8086 from C and also the C compiler should compile itself on DOS and 8086 :-)

> only format that definitely can't be
> used in DOS (that I know of) is Mach-O.
For 8086 development just binary and OMF are sufficient.

> Besides, I'm usually with the latest daily build of NASM.
TFM is still horrible, anyone cares ??? :-(

Arjay wrote:

> But I plan to have a test rack of some sorts again where
> I can literally quickly test stuff with a 8086, 80186, 286, 386
So you have 8086 and 80386 ? Would you occasionally do some tests maybe ?

- FreeDOS and EDR-DOS on 8086
- UI21DEB on 8086
- FreeDOS HIMEMX on 80386
- FASM on 80386
- 7-ZIP on 80386
- MPLAYER on 80486 (needs 32 MiB RAM, however)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Rugxulo

Homepage

Usono,
06.09.2010, 22:27

@ DOS386
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> > I believe cm is using NASM 2.04+ features in his port of
> > RxDOS. While I don't personally see a huge need to have a
> > 16-bit NASM just to assemble that, it would still be cool
>
> An 8086 DOS kernel done in pure ASM and compilable on 8086 would be very
> COOL :-)

What about the RxDOS (GPL) hack using A86 (shareware) instead of MASM? Even Japheth compiled one tiny piece of it with JWasm. But cm's NASM fork is probably better. Then again, no expectations, I think he's just doing it for fun, no timetable.

> Of course the assembler should compile from its source on 8086 and
> be done in pure ASM too.

WASM 2.23 (Wolfware) and Venksi's ASM-1.9 are the only free/libre, 8086-compatible ones that can assemble themselves, IIRC.

> If done in C then it should compile on 8086 from C
> and also the C compiler should compile itself on DOS and 8086 :-)
TC 2.01 or TC++ 1.01 can run on 8086, but they are closed source. OpenWatcom always needs a 386+ host. (And Debian hates OSI's approval of the Sybase license.) Any of those can compile FreeDOS's KERNEL.SYS.

> > only format that definitely can't be
> > used in DOS (that I know of) is Mach-O.
>
> For 8086 development just binary and OMF are sufficient.
ELKS probably uses what BCC/Dev86 uses, AS86 (a.out?) I guess.

> So you have 8086 and 80386 ? Would you occasionally do some tests maybe ?
>
> - FreeDOS and EDR-DOS on 8086
It was only "back in the day" that FreeDOS accidentally didn't run on 8086 (boot sector). Of course, FreeCOM 0.84-pre2 needs 186+ for having all features. Old 0.82pl3 "stable" should run anywhere (even with KSSF or VSPAWN).

> - FreeDOS HIMEMX on 80386
We already know HIMEMX, as is, has a 386 bug (RayeR??), but it's not patched officially, nobody got around to it, and nobody complained.

> - FASM on 80386
Should work, why wouldn't it? I tested a few months ago on (now disconnected) 486 Sx, ran fine.

> - 7-ZIP on 80386
mik's p7zip 4.57 ran on 486 Sx fine, IIRC, later versions didn't. Haven't tested Khrusaw's latest because the machine is packed up. Anyways, HX + 7ZA always worked, IIRC.

> - MPLAYER on 80486 (needs 32 MiB RAM, however)
32 MB + data = what, 64? Unlikely that any 486 has that. I think even original Pentiums never had more than that (motherboard limit???). But if you can find a suitable test machine .... (386EX might've supported 64 MB, but who outside of NASA or whoever still has that?)
DOS386

06.09.2010, 22:37

@ Rugxulo
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> What about the RxDOS (GPL) hack using A86 (shareware) instead of MASM?
The assembler should be free of course. Also, the old RxDOS is bugged.

> WASM 2.23 (Wolfware) and Venksi's ASM-1.9 are the only free/libre,
> 8086-compatible ones that can assemble themselves, IIRC.
Good, but aren't they just MASM 1 clones ???

> TC 2.01 or TC++ 1.01 can run on 8086, but they are closed source.
Bad

> OpenWatcom always needs a 386+ host.
There used to be WATCOM C 16 compiler 20 years ago :-|

> (And Debian hates OSI's approval of the Sybase license.
Not major problem for me ...

> Of course, FreeCOM 0.84-pre2 needs 186+ for having all
Considering the huge improvements in 80186 :-D

> We already know HIMEMX, as is, has a 386 bug (RayeR??), but it's not
> patched officially, nobody got around to it, and nobody complained.
Why don't those who have 80386 test it ???

> Should work, why wouldn't it? I tested a few months
> Anyways, HX + 7ZA always worked, IIRC.
Occasional retests would be good ...

> 32 MB + data = what, 64? Unlikely that any 486 has that. I think even
16 MiB EXE + 16 MiB data ( + the DeLL HeLL if HX is used ) ;-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Arjay

07.09.2010, 18:19

@ DOS386
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> Considering the huge improvements in 80186 :-D
 LOL! Don't forget that the 80186 was widely used in PC's... oh wait my mistake no it wasn't ;) Probably got used in more lifts than PC's!
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 18:53

@ Arjay
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> > Considering the huge improvements in 80186 :-D
And don't forget all the useful instructions added to the x86 instruction set with the famous 286! There's a lot of DOS software optimized for 286s! Oh wait it's the mistake of the programmers that state such non-sense, these instructions were added to the instruction set by the 186. (Because most programmers never bothered to check for the correct CPU before executing opcodes restricted to specific instruction sets, their documentation mistake doesn't hurt much anyway.) Although actual 186 chips might not have been used much in PCs, the NEC V20 and V30 had the 186 instruction set too.

---
l
Arjay

07.09.2010, 07:33

@ Rugxulo
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> (386EX might've supported 64 MB,
> but who outside of NASA or whoever still has that?)
 Embedded 386's were common at one time, e.g. voicemail systems, digital cameras.
Obviously a lot of stuff is now ARM but older embedded equipment and even some newer boxes are Intel based.
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 16:22

@ Rugxulo
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> What about the RxDOS (GPL) hack using A86 (shareware) instead of MASM?
RxDOS 7.1.5 is trash. So is A86; and it kinda defeats the purpose of using a self-recompiling assembler if you can't compile it because you lack the source code. (Actually, we don't even know whether A86 really is self-compiling.)

> Even Japheth compiled one tiny piece of it with JWasm.
Yeah. You could arguably make (a)7.1.5 work with JWasm with little effort, but it's still trash.

> But cm's NASM fork is probably better.
It's neither a fork nor a port any more. I've probably rewritten at least 50% of the code by now.

> Then again, no expectations, I think he's just doing it
> for fun, no timetable.
True. Expect releases in early 2038. (In the year 2038, that is.)

> (And Debian hates OSI's approval of the Sybase license.)
It's still the best 16-bit DOS compiler though, isn't it? If I had the choice maybe I would use a 2-clause BSD compiler with OpenWatcom's capabilities instead.

> Any of those can compile FreeDOS's KERNEL.SYS.
Now you could back up TC's alleged ability to produce small code. Do you have the necessary setup to compare a TC compile of TFK with an OpenWatcom compile?

> > For 8086 development just binary and OMF are sufficient.
>
> ELKS probably uses what BCC/Dev86 uses, AS86 (a.out?) I guess.
That's a somewhat exotic environment. Besides, they probably don't have NASM syntax source code anyway, do they?

It's still a good answer to that statement though.

> Of course, FreeCOM 0.84-pre2 needs 186+ for having all features.
Ahahahahah. Are you kidding us, or are they? True, the new 186 instructions are useful, but they can all easily be replaced by equivalent 8086 code. With a few macros, you probably wouldn't even have to touch the code.

These are the instructions exclusive to 186+:

* POPA/PUSHA
* SHL/SHR/SAR/ROL/ROR/RCL/RCR with immediate
* ENTER, LEAVE
* Did I forget any? Yes: PUSH immediate, and some less useful: BOUND, IMUL immediate, string I/O.

Besides the ones I called less useful, you can replace all of these using simple macros. Then there's just a few things on the 8086 to be considered, like invalid opcodes not throwing Int06 and shift counts in cl ain't limited.

> and nobody complained.
How about somebody complain about it now?

---
l
Rugxulo

Homepage

Usono,
07.09.2010, 16:59

@ ecm
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> > What about the RxDOS (GPL) hack using A86 (shareware) instead of MASM?
>
> RxDOS 7.1.5 is trash.

I don't know. It seems somewhat incomplete. Also seemed floppies I used for it got corrupted and had to be rewritten over and over. Maybe that was my fault, dunno. (Also never could figure out which version was the last / most recent.) But at least it tries to support FAT32 and LFN ("modern" technology). Still, it's GPL, so we can't complain! :-)

Probably broadly similar to DOS-C, which was originally just an int 21h API, not all the extra bells and whistles. It didn't run everything under the sun either originally.

> So is A86;

Whoa! Kinda strong statement. I don't think anybody reasonably thinks A86 is crap. It's not. But yeah, it hasn't been developed since 2000, so it only supports SSE1 *sniff* j/k. :lol2: I'll admit that it has some quirks that I don't like, and it's fairly limited in OS support (obviously), but it works fairly well for what it does. There are some assemblers that mimic A86 in minor ways (due to being written in it?), but they are incomplete in their compatibility too. Face it, x86 asm has no standard, so everyone varies the syntax a fair bit.

> and it kinda defeats the purpose of using
> a self-recompiling assembler if you can't compile it because you lack the
> source code.

Well, the point was that A86 can run on 8086 and compile that fork of RxDOS, which is what DOS386 wanted (in theory). I didn't say it was ideal, just saying it exists, so it's better than nothing!

> (Actually, we don't even know whether A86 really is self-compiling.)
A86 is (allegedly) self-compiling, if you believe the author.

> > Even Japheth compiled one tiny piece of it with JWasm.
>
> Yeah. You could arguably make (a)7.1.5 work with JWasm with little effort,
> but it's still trash.
I assume you mean due to bugs. That, to me, is more of a deal-breaker than incompleteness.

> > But cm's NASM fork is probably better.
>
> It's neither a fork nor a port any more. I've probably rewritten at least
> 50% of the code by now.
Well, it's still a derivative.

> > Then again, no expectations, I think he's just doing it
> > for fun, no timetable.
>
> True. Expect releases in early 2038. (In the year 2038, that is.)
The next Y2K problem. ;-)

> > (And Debian hates OSI's approval of the Sybase license.)
>
> It's still the best 16-bit DOS compiler though, isn't it? If I had the
> choice maybe I would use a 2-clause BSD compiler with OpenWatcom's
> capabilities instead.
Here's what bugs me about that:

* Nobody at Sybase probably cares anymore. Nobody seems interested. They don't seem to actively maintain or even ever plan to change the license. So it's pretty much "dead" legally, IMHO.

* OSI approves the license, tons of it has been reworked, tweaked, improved since then, but it's still not good enough for Debian. And they somehow take that to mean that FreeDOS proper should stay in "multiverse", which seems odd to me. What does the compiler have to do with the license of the compiled output? In this case, nothing, but they are being more than a little silly. (Or maybe they're worried about patents, but I'd be VERY surprised if anybody tried anything. And no, VFAT isn't in FreeDOS proper, so that can't be a good reason against it.)

* There is no real effort to port FreeDOS to any other compiler. Of course, what else is there? There are other C compilers, but almost all of them only support 32-bit. So what, we should only use a 32-bit DOS now? Maybe.

> > Any of those can compile FreeDOS's KERNEL.SYS.
>
> Now you could back up TC's alleged ability to produce small code. Do you
> have the necessary setup to compare a TC compile of TFK with an OpenWatcom
> compile?
What is TFK?

My P166 has OW 1.8 and TC++ 1.01. Both are freely available (loosely speaking, you pedants). For instance, BEF.C from bef-2.21.zip (Chris Pressey) compiles and UPXes to approx. 17k in OW but 10k in TC++. So it is smaller, but only because (says Tom Ehlert) that it's a "dumber" compiler (one-pass??).

> > > For 8086 development just binary and OMF are sufficient.
> >
> > ELKS probably uses what BCC/Dev86 uses, AS86 (a.out?) I guess.
>
> That's a somewhat exotic environment. Besides, they probably don't have
> NASM syntax source code anyway, do they?
No, but if someone wanted to write for ELKS with NASM .... I'm only mentioning this to be complete. ELKS has even less users than FreeDOS (not many)!

> > Of course, FreeCOM 0.84-pre2 needs 186+ for having all features.
>
> Ahahahahah. Are you kidding us, or are they? True, the new 186 instructions
> are useful, but they can all easily be replaced by equivalent 8086 code.
> With a few macros, you probably wouldn't even have to touch the code.
It has something to do with size, I never looked to closely. Yes, I know, it shouldn't be an issue, but it is. Blame the lame-o C compilers.

> * POPA/PUSHA
> * SHL/SHR/SAR/ROL/ROR/RCL/RCR with immediate
*ding ding* These are probably the only affected instructions. Actually, I can't remember, it may just be something like LOADFIX and/or something else trivial that isn't in the pure 8086 build. I haven't rebuild FreeCOM lately.

> > and nobody complained.
>
> How about somebody complain about it now?
About HimemX? The patch is on this forum somewhere. Somebody (RayeR?) did test it, and it didn't work until patched. Eric Auer even showed some interest, but he seemed to (apparently) want me to patch / upload it. Well, it's not like I really expected him to either. I dunno, everything's just so disorganized, too much to do, not enough volunteers, etc.

---
Know your limits.h
Arjay

07.09.2010, 18:04

@ Rugxulo
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> > So is A86;
> Whoa! Kinda strong statement. I don't think anybody reasonably thinks A86
 I agree. I think it is also worth remembering there wasn't a lot of choice when A86 was first out. For a low cost assembler it was good in its day.


>> is crap.
> It's not. But yeah, it hasn't been developed since 2000,
I can't remember exact dates but I know AWBAT (Win32 "tweak") was developed until 2003. I have a D86 here also dated 2005. Eric does still respond to emails at least to registered folks - certainly the case couple of years ago.

> the point was that A86 can run on 8086 and compile that fork of RxDOS
 I think it is fair to say A86 has its downsides but also its positives. It is also nice if you want to compile simple progs without complex syntax's and yes as you've pointed out it runs on pretty much anything. Indeed I've not found anything it wouldn't run on including even "embedded" 286 typewriters !

> > (Actually, we don't even know whether A86 really is self-compiling.)
> A86 is (allegedly) self-compiling, if you believe the author.
 I do.

> > True. Expect releases in early 2038. (In the year 2038, that is.)
> The next Y2K problem. ;-)
 Don't worry there are a few before 2038.... 2010, 2011 (Y1C), 2036. Off the top of my head I also have 2017 in my mind but can't remember why/which platform. The added bonus is a number of systems were "fixed" in Y2K by as I understand it adjusting date fields "slightly" into the future in many cases 30 years=2030.

> * Nobody at Sybase probably cares anymore. Nobody seems interested. They
> don't seem to actively maintain or even ever plan to change the license.
The folks who probably knew understood it left, retired or are now senior managers who have moved away from techi work or are simply too busy elsewhere.

> So it's pretty much "dead" legally, IMHO.
 Typo? I think you meant IANAL not IMHO ;-)
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 19:15

@ Arjay
 

NASM version 2.09 available | A86

Post reply

> For a low cost assembler it was good in its day.
That might be true.

> It
> is also nice if you want to compile simple progs without complex syntax's
org 100h

label:
mov dx, message
mov cx, message.end - message
mov bx, 1
mov ah, 40h
int 21h

jmp short .locallabel

; The jump isn't required of course.

.locallabel:
mov ax, 4C00h
int 21h

message:
db "Now tell me this is complex syntax.",13,10
.end:

I don't doubt that you can write simple programs in A86 easily, but so can I in NASM. The difference is that NASM is better at complex programs while still allowing the simple syntax for simple stuff. (For the record, I could have called Int21.09 but I don't like it that much.)

> and yes as you've pointed out it runs on pretty much anything. Indeed I've
> not found anything it wouldn't run on including even "embedded" 286
> typewriters !
I would think running on as low as an 8086 is related to it being available for that long too. Like all I've written by now, this points to A86 being outdated.

> [...], if you believe the author.
 >
> I do.
I do too. That wasn't the point.

---
l
Arjay

07.09.2010, 19:58

@ ecm
 

NASM version 2.09 available | A86

Post reply

Firstly I don't want to get into this is better than that type of discussions particularly as I'm not a fan of any particular tool; I use what is to hand.

Still just for fun I thought I would do a quick compare using your example:


> label:
 LABEL is reserved word in MASM, A86, TASM? So A86 will only compiles your program if LABEL is fixed, e.g. LABEL1. The next issue is the line length is then calculated wrong-only because A86 doesn't understand the syntax you used.

However this slightly altered version compiles fine with both A86 and NASM:


org 100h

label1:
mov dx, message
mov cx, message_end - message
mov bx, 1
mov ah, 40h
int 21h

jmp short .locallabel

; The jump isn't required of course.

.locallabel:
mov ax, 4C00h
int 21h

message:
db "Now tell me this is complex syntax.",13,10
message_end:


The above version compiles to 57 bytes with both compilers (binary match).


IMHO this is a more readable version which compiles with both (note I a recent NASM version) and is 52 bytes (binary match):

org 100h

displaymsg:
  mov dx, message
  mov ah, 9h
  int 21h
  mov ax, 4C00h
  int 21h

message:
  db "Now tell me this isn't more readable!",13,10,"$"



> I don't doubt that you can write simple programs in A86 easily,
> but so can I in NASM.
 I think it is important to remember you can write complex programs in pretty much anything. Obviously most of the time it makes sense to do things the easy way if easier tools exist. There are times/people who like to do things the complex way as well though. Depending on what I'm doing I can be either!

> The difference is that NASM is better at complex programs while
> still allowing the simple syntax for simple stuff.
FYI, I have used A386 (A86's brother) to write Win32 stuff quite happily. I can't compare NASM in that regards as to be honest I've not used it for Win32.

> Int21.09 but I don't like it that much.)
 Any particular reason?


> I would think running on as low as an 8086 is related to it being available
> for that long too.
Well run ability shouldn't always be assumed particularly as some boxes, e.g. CPM/bespoke systems don't boot in full IBM modes or don't have them. The typewriter I mentioned for example uses a 40x3 LCD screen which operates using A000h all the time including text modes. Obviously not easy to use ;)


> Like all I've written by now, this points to A86 being outdated.
 Fully agree, thus NASM is a good choice now. Still for those of us with A86 and A86 formatted code/libraries be aware we may occasionally still use it.
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 22:42

@ Arjay
 

NASM version 2.09 available | A86

Post reply

> Still just for fun I thought I would do a quick compare using your
> example:
Okay, but, uhm, you do know it was supposed to be a NASM-only example?

> LABEL is reserved word in MASM, A86, TASM? So A86 will only compiles your
> program if LABEL is fixed, e.g. LABEL1.
NASM allows access to reserved words by prefixing them with '$'. That can be done automatically using macros (so that you can actually use the unprefixed word as label).

> and is 52 bytes [...]
Yup, you could write smaller code! Try this:

        mov ah, 02h
        mov dl, '!'
        int 21h
        retn

Note how this is both less source code and a smaller binary (7 byte). The source code was freed from all the unnecessary red tape. It also makes our user interface less obstructive than ever.

>   mov ah, 9h
Why not "mov ah, 9" then? This is worse than both alternatives!

>   db "Now tell me this isn't more readable!",13,10,"$"
It's not. Why is there a dollar sign behind all your messages? What's that do? I don't get it. /BLAHMODE

> > I don't doubt that you can write simple programs in A86 easily,
> > but so can I in NASM.
 >
> I think it is important to remember you can write complex programs in
> pretty much anything.
How does this program look in A86? Note that here, you can add code to the installation or TSR section as necessary and all the segment arithmetic is automatically fixed up. The vstart option makes the TSR section work as a separate segment, that is, the labels there are addressed as if the section's beginning was at address 0. Besides that, note the relevant size calculations and how actually NASM isn't trying to do the segment setup here; I am doing it. Of course I usually write macros to make such complicated segment setup and access easier, this is the "unrolled" form.

        cpu 8086
        org 100h

        section TRANSIENT

transient:
        mov ah, 52h
        int 21h
        mov ax, word [ es:bx-2 ]
        push cs
        pop es
.loop:
        mov ds, ax
        inc ax
        cmp word [ 1 ], ax
        jne .next
        cmp word [ 3 ], resident_size_p
        jne .next
        mov si, 8
        mov di, residentmcb+8
        mov cx, si
        rep cmpsb
        jne .next

        push ax
        mov ax, 3521h
        int 21h
        pop ax
        cmp bx, handler
        jne .error
        mov bx, es
        cmp ax, bx
        jne .error

        push ds
        lds dx, [ 10h + handler.next ]
        mov ax, 2521h
        int 21h

        pop ds
        mov word [ 1 ], 0

        mov dx, 'U'
        jmp short .exit

.error:
        mov dx, (0FFh<<8)+'!'

.exit:
        mov ah, 02h
        int 21h

        mov ah, 4Ch
        mov al, dh
        int 21h

.next:
        add ax, word [ 3 ]
        cmp byte [ 0 ], 'M'
        je .loop

        mov ax, cs
        add ax, 10h+transient_size_p
        mov ds, ax
        mov ax, 3521h
        int 21h
        mov word [ handler.next +2 ], es
        mov word [ handler.next ], bx
        mov ah, 25h
        mov dx, handler
        int 21h

        mov ax, cs
        mov ds, ax
        add word [ residentmcb + 1 ], ax

        dec ax
        mov es, ax
        mov bl, byte [ es:0 ]
        mov ax, word [ es:3 ]

        sub ax, 10h+transient_size_p+resident_size_p+1
        mov word [ newmcb + 3 ], ax
        mov byte [ newmcb + 0 ], bl

        mov sp, $-$$+100h&~1
        mov word [ es:3 ], 10h+transient_size_p-1
        mov byte [ es:0 ], 'M'

        mov dx, 'I'
        jmp short .exit


        align 16
residentmcb:
        db 'M'
        dw 10h+transient_size_p
        dw resident_size_p
        db 0,0,0
        db "I21HOOK",0

; I'd usually do these equates in a macro
transient_size equ $-transient
transient_size_p equ transient_size+15>>4

        section RESIDENT vstart=0 align=16
resident:

handler:
        ; Do Int21 hook functionality here.
        jmp 0:0
.next:  equ $-4

resident_size equ $-resident
resident_size_p equ resident_size+15>>4

        section NEWMCB align=16
newmcb:
        db 0
        dw 0
        dw 0
        times 3+8 db 0

> Obviously most of the time it makes sense to do
> things the easy way if easier tools exist.
The easiest way (speaking of simple syntax) would be using nothing but db. That doesn't require a complex assembler either. This is an extreme comparison, but my point here is that doing things the easy way isn't what you should prefer most of the time - I usually prefer higher readability of the source code. (This doesn't mean using HLL macros to write your code for you. It means writing real code in a way so it's readable.)

> I can't compare NASM in that regards as to be honest I've not used it for
> Win32.
I've used neither for any real Win32 effort but then again it just doesn't interest me. I don't see why it would be necessary to write for a Win32 platform, DOS programs done right are complex enough.

> > Int21.09 but I don't like it that much.)
 >
> Any particular reason?
It uses a dollar sign as string terminator. That is silly. (It also doesn't allow displaying device names, as they'll often contain dollar signs.)

> Obviously not easy to use ;)
Yeah.. I would assume D86 doesn't work there :-P

> Still for those of us with A86 and A86 formatted
> code/libraries be aware we may occasionally still use it.
I never said anything against that ;-)

---
l
DOS386

08.09.2010, 01:05

@ ecm
 

NASM 2.09 available | A86 | FASM | Arjay's 8086+80386 PC's

Post reply

> Yes, I would be happy to do occasional tests hence mention re my hardware.
Thanks :-)

1. Does your 8086 have at least 640 KiB RAM ? What floppy does it have ? 3+1/2 1.4 MiB would be cool but I doubt ...
2. How much RAM does your 80386 have ?
3. How much RAM does your 80486 have ? MPlayer needs at least 32 MiB, 7-ZIP might work with less too (if you set dict size properly)

You might get mail one day ;-)

> NASM allows access to reserved words by prefixing them with '$'. That can
> be done automatically using macros (so that you can actually use the
> unprefixed word as label).
But things like

MOV EAX, $FEDC'1234

will never work in any assembler except FASM :-)

> * There is no real effort to port FreeDOS to any other compiler.

As there is no usable alternative ...

> But at least it tries to support FAT32 and LFN ("modern" technology)
:lol:

> > > And no, VFAT isn't in FreeDOS proper,
> > so that can't be a good reason against it.)
> VFAT is in Linux, so what?
Deprecate it ;-)

> It is also nice if you want to compile simple progs without complex syntax
FASM can too and very well :-) ... just not on 8086 :-(

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Japheth

Homepage

Germany (South),
08.09.2010, 09:26

@ DOS386
 

FASM and OMF

Post reply

> FASM can too and very well :-) ... just not on 8086 :-(
I cat't remember if it has been mentioned ever, so I'll take the burden:

FASM doesn't know OMF output format, which makes it rather inadequate for DOS programming. :-(

---
MS-DOS forever!
DOS386

08.09.2010, 19:40

@ Japheth
 

16-bit DOS COBOL, 16-bit DOS PASCAL, 16-bit DOS C, 16-bit

Post reply

> I cat't remember if it has been mentioned ever, so I'll take the burden:
> FASM doesn't know OMF output format
Right.

> which makes it rather inadequate for DOS programming
NOT true (except the special case you want to mix ASM with some weird stuff like 16-bit DOS COBOL, 16-bit DOS PASCAL, 16-bit DOS C, 16-bit DOS C+++, 16-bit DOS FORTRAN, Quack-BAYSIC, ... etc) ;-)

cm wrote:

> My assembler is freer than yours!
I don't get it :confused: - explain please :hungry:

> NASM doesn't have Copyleft
only Copyright ???

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
08.09.2010, 19:45

@ DOS386
 

16-bit DOS COBOL, 16-bit DOS PASCAL, 16-bit DOS C, 16-bit

Post reply

> > which makes it rather inadequate for DOS programming
>
> Not true (except the special case you want to mix ASMassembly with [...]).
Ahahahahahah. Or assembly. Think libraries.

> cm wrote:
 >
> > NASM doesn't have Copyleft
>
> Only Copyright???
Yes, it lacks any Copyleft and only has copyright.

---
l
DOS386

08.09.2010, 19:53

@ ecm
 

16-bit DOS COBOL, 16-bit DOS PASCAL, 16-bit DOS C, 16-bit

Post reply

> Ahahahahahah. Or assembly. Think libraries
compiled from aforementioned ;-)

> Yes, it lacks any wikipedia.org/wiki/Copyleft and only has copyright.
Same for FASM. So how can NASM be more free ???

Even worse, my Copyleft stuff is Public Domain so it has already the most free license ever, impossible to beat :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
08.09.2010, 20:02

@ DOS386
 

FASM is copylefted

Post reply

> Same for FASM. So how can NASM be more free???
No, FASM uses a custom "2-clause BSD with Copyleft" license. To quote the LICENSE.TXT file I found in my FASM download:

flat assembler  version 1.69
Copyright (c) 1999-2010, Tomasz Grysztar.
All rights reserved.

This program is free for commercial and non-commercial use as long as
the following conditions are adhered to.

Copyright remains Tomasz Grysztar, and as such any Copyright notices
in the code are not to be removed.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The licence and distribution terms for any publically available
version or derivative of this code cannot be changed. i.e. this code
cannot simply be copied and put under another distribution licence
(including the GNU Public Licence).

> Even worse, my Copyleft stuff is Public Domain so it has already the most
> free license ever, impossible to beat :-)
Non-sense. Did you even read the linked article? Real Public Domain works can't be Copylefted.

---
l
ecm

Homepage E-mail

Düsseldorf, Germany,
08.09.2010, 15:09
(edited by cm, 08.09.2010, 15:23)

@ DOS386
 

NASM - FASM

Post reply

> But things like
>
> MOV EAX, $FEDC'1234
>
> will never work in any assembler except FASM :-)
Face it: No one except you uses that notation :-P

Besides, it wouldn't be that hard to add this behaviour to NASM. My assembler is freer than yours! (NASM doesn't have Copyleft.)

---
l
Arjay

08.09.2010, 22:12
(edited by Arjay, 08.09.2010, 22:33)

@ DOS386
 

NASM 2.09 available | A86 | FASM | Arjay's 8086+80386 PC's

Post reply

> 1. Does your 8086 have at least 640 KiB RAM ?
I have a few 8086/80186's with various specs. To be honest as it is so long since I've fired them up I don't remember their exact specs off the top of my head, however I am pretty sure the following will be fairly accurate:

1) A single 8086 laptop probably with twin 720k drives and 640k. 2) A single 8086 desktop certainly with 640k which I put it in a chip at a time :) 3) 2
RM Nimbus's 80186's 1 with a hard drive and a single 720k and the other one with twin 720k's and if my memory serves me correctly I also have 4 complete Nimbus motherboards from when I gutted 20+ of the things. I also have a rare system programmers manual and other technical information on them.
4) A single 8086 Tiny PC - basically it is a 8086 in the size of a shoe box with a single 720k drive, TV output, and was made around 1991 (i.e. late) was fairly cool compared with the crap that went on to sell later on before they went bust!

> What floppy does it have ?
 Mostly on those machines 720k's. However I have I collected a few controllers and drives separately on purpose.... So I know I have at least 2 * 5 1/4" 360k full height drives, 2 * 360k half heights, 2 * 1.2, and several 720k and 1.44 drives, Basically in terms of drives I do a good line in everything except 20" 8" and newer stuff like 2.88 etc

> 3+1/2 1.4 MiB would be cool but I doubt ...
 As above I can cover both :) Btw one of these days I will switch to using MiB still doesn't seem right :)

> 2. How much RAM does your 80386 have ?
 I think around 4Mb possibly more as I pimped that box to run my BBS which had around 4Gb circ 1993. Again hasn't been switched on for years (in storage).

> 3. How much RAM does your 80486 have ?
32Mb I think. It was my Linux dialup gateway for years.

> MPlayer needs at least 32 MiB, 7-ZIP
> might work with less too (if you set dict size properly)
 I can locate some extra RAM. Also if need be I'll free some used crap ;)

> You might get mail one day ;-)
 Oh great. I used to get a lot but purposefully went quite for years. Oh dear....


> > NASM allows access to reserved words by prefixing them with '$'.
Thanks useful tip.

> FASM can too and very well :-) ... just not on 8086 :-(
 I've dabbled with FASM. Nice to have so much choice these days.
DOS386

11.09.2010, 01:23

@ Arjay
 

NASM 2.09 available | A86 | FASM | Arjay's 8086+80386 PC's

Post reply

> we should focus on DOS emulation
Because ??? This will finally upgrade DOS from this absurd toy running inside Windaube to a serious participant on the OS market ??? So "we" can expect DOS versions of Firefox, Opera, Gimp, PGP/GNUPG, OpenOffice, AdobeAcrobe/Foxit/SumatraPDF, Wing-ZIP/Wing-RAR/Wing-ACE/Wing-RK, Notepad+/++/2/3, AdobePhotosh**, AutoCAD, VLC, Jawa/LimeWire, ... &Co ?

> which is " teh futurez !"
Slangy word for past 20 years ???

> Real Public Domain works can't be Copylefted.
Since they per definition must be (no Copyright) ;-)

> No, FASM uses a custom "2-clause BSD with Copyleft" license
So NASM is more free because it lacks the restriction prohibiting to switch it to the more restrictive GPL ? This is cool :lol:

Arjay wrote:

> > 3+1/2 1.4 MiB would be cool but I doubt ...
> As above I can cover both
So if I send a 3+1/2 1.4 MiB floppy (as image) you could boot it into some 8086 PC ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
11.09.2010, 01:53

@ DOS386
 

NASM - FASM license

Post reply

> > Real Public Domain works can't be Copylefted.
>
> Since they per definition must be (no Copyright).
Now you're either just ignorant or trolling. Read the article I linked. "Copyleft" is not the absence of copyright. Public Domain works are neither Copylefted nor copyrighted. (Technically they might be copyrighted but the copyright's owner grants you all rights, without any kind of warranty.)

> > No, FASM uses a custom "2-clause BSD with Copyleft" license
>
> So NASM is more free because it lacks the restriction prohibiting to
> switch it to the more restrictive GPL?
That's how software licensing works boy. Note that with the modified emphasis, your statement is very clear on why NASM is freer - its license is less restrictive. You are free to copy NASM's source code partly or in whole and then use that in other works (be they proprietary, GPL, or under most any other software license) with only minimal requirements. This of course doesn't mean you can enforce usage of your new version instead of the official NASM version, so you can't restrict the original this way.

I won't explain Copyleft to you too. Just look it up already!

FASM's license contributes to what is called "license proliferation", and because of the comment regarding the GPL I think that is intentional. This means, even though FASM's license is similar to the GPL with Copyleft (look it up!) and all, it is incompatible with other such Copyleft licenses. It might be interesting that technically, FASM's license might have been GPL-compatible if not for explicitly prohibiting the GPL - because distribution under the GPL's terms would insure all the requirements of the FASM license are met. The GPL would then only add restrictions, which isn't prohibited by the FASM license.

---
l
Arjay

13.09.2010, 13:31

@ DOS386
 

NASM 2.09 available | A86 | FASM | Arjay's 8086+80386 PC's

Post reply

> So if I send a 3+1/2 1.4 MiB floppy (as image) you could boot it into some
> 8086 PC ?
Yes, I am happy with most image formats and am able to convert image formats.

However at this moment in time I can only offer to test 720k disks or twin 720k (A: + B:) disks on 8086/8088's and 640k of memory. The reason for this limitation is simply that I currently only have easy access to a 8088 clone laptop with 640k/CGA. I do however have easy access to 80286's with VGA.
Rugxulo

Homepage

Usono,
08.09.2010, 06:56

@ ecm
 

NASM version 2.09 available | A86

Post reply

> > For a low cost assembler it was good in its day.
>
> That might be true.
Compared to MASM or TASM.

> I would think running on as low as an 8086 is related to it being available
> for that long too. Like all I've written by now, this points to A86 being
> outdated.
Sure it's outdated. It hasn't been officially updated in ten years, it lacks anything newer than SSE1, it only runs on DOS, and it only outputs raw binary or OBJ/OMF. That's not enough these days (unless you only use DOS/OMF and don't need newer instructions). Not saying it isn't good, but admittedly it could be improved. NASM wins these days.

Part of the appeal (I think) for RxDOS was that it ran in little memory and fast, so that RxDOS could even run it too. Well, plus it was shareware, available everywhere (Simtel), unlike MASM. But RxDOS never took off, nor OpenDOS, only DOS-C because of the friendlier GPL license and C codebase (which was easier for the devs).

---
Know your limits.h
Rugxulo

Homepage

Usono,
08.09.2010, 06:28

@ Arjay
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> >> is crap.
> > It's not. But yeah, it hasn't been developed since 2000,
> I can't remember exact dates but I know AWBAT (Win32 "tweak") was developed
> until 2003. I have a D86 here also dated 2005. Eric does still respond to
> emails at least to registered folks - certainly the case couple of years
> ago.
AWBAT is a hack, and I don't think even EJI himself would deny that. (Uses ALINK 1.7 beta, right? BTW, that guy [A.W. in U.K.] dropped by OW's newsgroup a few months ago to talk about multi-threading.) I'm not saying it isn't good, but ... well it seemed fairly minimal when I looked years ago. (Besides, I had no interest in Windows, and not even now except compiling portable code to run there via FPC or Cygwin or similar.) Of course I would think FASM is more suitable nowadays (and with better examples, e.g. FASMW), no offense to EJI's hard work, he's very talented.

Someone told me they asked him to port A86 to Linux, but he refused. (Unreleased Isforth for DOS, ah well.)

His website still lists 4.05 as latest, so apparently he hasn't updated it officially since then (2000). IIRC, D86 had some binary patch to use 386 debug registers, which modifies the timestamp (hence your 2005 remark ??). I'm not saying you're wrong, but I don't know of any new updates or additions in past years.

---
Know your limits.h
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 18:42

@ Rugxulo
 

NASM version 2.09 available | A86 and kernels

Post reply

> (Also never could figure out which version was the last / most recent.)
Still 7.1.5, from the FreeDOS mirrors. It's also the only one clearly licensed under the GPL. "a7.1.5" is the A86 port of that version. There's numerous other releases but all either without or with non-free source, and mostly older.

> Still, it's GPL, so we can't complain! :-)
I complain as a user, not as a developer. No, wait, I do complain as a developer too. There's nothing in the GPL to prevent me from that :-)

> > So is A86;
>
> Whoa! Kinda strong statement. I don't think anybody reasonably thinks A86
> is crap. It's not.
Yeah.. maybe it's a little too strong, but A86 isn't sophisticated at all. Even include files weren't supported for several years! The local label mechanism is crap and doesn't work together with D86 either. Given that the assembler and debugger are highly integrated, I would assume that to work. D86 also isn't very sophisticated, technically. For example, it catches Int21.4C of the debugged code, presumably with an Int21 hook - a nice feature? Not only that, it's also necessary for no-program operation because D86 doesn't set up a child process that way (and would then terminate itself by 21.4C, incompletely, because it doesn't catch its own termination). Besides, the whole symbolic debugging and most of D86's interface is designed for programs running in exactly one segment. The former is virtually unusable for large, or multiple, programs (f.e. kernels) in multiple segments.

What I have to give D86 is its good implementation of "memory windows" (automatically updated data dumps) and the extensive online help. Surely just writing all the text took some effort, let alone programming the automatic context-sensitive displaying of the correct help pages.

> But yeah, it hasn't been developed since 2000, so it only supports SSE1
That really doesn't bother me.

> Well, the point was that A86 can run on 8086 and compile that fork of
> RxDOS, which is what DOS386 wanted (in theory). I didn't say it was ideal,
> just saying it exists, so it's better than nothing!
It has been acknowledged. I just wouldn't develop anything on A86 no matter how much I care for 8086 compatibility.

> > (Actually, we don't even know whether A86 really is self-compiling.)
>
> A86 is (allegedly) self-compiling, if you believe the author.
That's what I said. Although I don't really doubt that it is self-compiling: unless we have the source, we can't know for sure.

> > RxDOS 7.1.5 is trash.
>
> [...]
 >
> But at least it tries to support FAT32 and LFN ("modern" technology).
 >
> [...]
 >
> Probably broadly similar to DOS-C, which was originally just an int 21h
> API, not all the extra bells and whistles. It didn't run everything under
> the sun either originally.
 >
> [...]
 >
> > Yeah. You could arguably make (a)7.1.5 work with JWasm with little
> effort,
> > but it's still trash.
>
> I assume you mean due to bugs. That, to me, is more of a deal-breaker than
> incompleteness.
I stopped recording specific bugs about 4 months into the hacking. There's no bugs any more; instead, everything just works hardly at all. I don't think DOS-C ever was that bad, but I didn't read Pat's book "FreeDOS Kernel" looking for problems specifically, and never looked at other early DOS-C source code.

> > > But cm's NASM fork is probably better.
> >
> > It's neither a fork nor a port any more. I've probably rewritten at
> least
> > 50% of the code by now.
>
> Well, it's still a derivative.
The kernel still is. But what if I get to a point where I've rewritten everything? Could I release it as my work? Would anyone even care to check the code? Probably not. (Don't misconstrue this. I don't want to steal any of Mike's code. Rewriting everything just really is a possibility.)

> The next Y2K problem.
Oh you. I wasn't aiming for that, 38 just is a nice number.

> Here's what bugs me about that:
>
> * Nobody at Sybase probably cares anymore. Nobody seems interested. They
> don't seem to actively maintain or even ever plan to change the license. So
> it's pretty much "dead" legally, IMHO.
Like about 95% of DOS software, only for that we don't get the source at all. So it was pretty nice of them to give us even "semi-free" source code, don't you think?

> * OSI approves the license, tons of it has been reworked, tweaked, improved
> since then, but it's still not good enough for Debian. And they somehow
> take that to mean that FreeDOS proper should stay in "multiverse", which
> seems odd to me.
Ah, that's where you're coming from.

> What does the compiler have to do with the license of the compiled output?
They're Linux zealots. They can't accept that there might be cases were accepting binaries instead of recompiling everything might be better, even if these binaries are just for a deprecated, foreign architecture no one supports.

Solution: Change people. Or use a workaround, for example, provide a free-free-free compiler for them. (Extend gcc? Use some existing DOS compiler with GPL or a really free license?)

Oh! Try embedding the KERNEL.SYS file in a C source file then compiling that with gcc :-D

> (Or maybe they're worried about patents, but I'd be VERY
> surprised if anybody tried anything.
What with the kernel developers declining to debug or even thoroughly test MS-DOS, all patents applicable to TFK would be equally applicable to Linux (the kernel).

> And no, VFAT isn't in FreeDOS proper,
> so that can't be a good reason against it.)
VFAT is in Linux, so what?

> * There is no real effort to port FreeDOS to any other compiler. Of course,
> what else is there? There are other C compilers, but almost all of them
> only support 32-bit. So what, we should only use a 32-bit DOS now? Maybe.
And write proper boot loading and PM start-up code. That means in assembler, you hacks! :-P

> What is TFK?
The FreeDOS Kernel. Because someone worked on some private (fork?) project they called DOS-C, they objected to me calling the recent FreeDOS kernel DOS-C on the mailing list, so I just call it The FreeDOS Kernel all the time. Calling it KERNEL.SYS isn't quite right in some situations.

> My P166 has OW 1.8 and TC++ 1.01. Both are freely available (loosely
> speaking, you pedants). For instance, BEF.C from bef-2.21.zip (Chris
> Pressey) compiles and UPXes to approx. 17k in OW but 10k in TC++. So it is
> smaller, but only because (says Tom Ehlert) that it's a "dumber" compiler
> (one-pass??).
Seems somewhat extreme. As pedant, I believe a one-pass compiler wouldn't be better than a multi-pass one. Maybe bad OW configuration (use "-os" or so to optimize for size)? There might also be more/better run-time checks in OW.

> ELKS has even less users than FreeDOS (not many)!
How would that be possible now. ;-)

> It has something to do with size, I never looked to closely. Yes, I know,
> it shouldn't be an issue, but it is. Blame the lame-o C compilers.
There's at least one PUSH imm opcode in one of the (NASM) source files. And FreeDOS is just silly enough I would expect something like that of them. Even if there are issues with segment size, no problem, split the offending code segment and do calls between these segments through pointers fixed up (preferably by the assembler swopping code).

> Actually, I
> can't remember, it may just be something like LOADFIX and/or something else
> trivial that isn't in the pure 8086 build.
Given that LOADFIX is absolutely useless on true 8086 and 80186 processors (they only address 1024 KiB of memory, there's no HMA or A20) you selected a bad example ;-)

As I said, the FreeCOM version I examined (0.84-pre XMS_Swap, 2005-07-20) really does have 8086-incompatible code. (Only seen it in an XMS call function though, and XMS doesn't exist on true 8086 machines, does it? Still bad enough.)

> I haven't rebuild FreeCOM lately.
Either way, fixing the broken 8086 compatibility should be a very easy task.

> I dunno, everything's just
> so disorganized, too much to do, not enough volunteers, etc.
I fondly regard Robert's mail asking about how FreeDOS 1.1 tasks are organized. And Pat's very inexplicit answer... "assessing what needs to be done in order to scope out the effort". Heheheheheh.

---
l
Rugxulo

Homepage

Usono,
08.09.2010, 06:49

@ ecm
 

NASM version 2.09 available | A86 and kernels

Post reply

> > But yeah, it hasn't been developed since 2000, so it only supports SSE1
>
> That really doesn't bother me.
Nor me, but it just means he hasn't kept it up. Granted, I personally can't help but wonder if we've "jumped the shark" on x86, adding so many things (SSSE3, SSE4.1, XOP, AVX) in addition to obvious things like FPU, MMX, SSE2, AMD64. You're right when you say A86 is dated. It's still good for lots of uses, though I don't personally use it much anymore.

> > > (Actually, we don't even know whether A86 really is self-compiling.)
> >
> > A86 is (allegedly) self-compiling, if you believe the author.
>
> That's what I said. Although I don't really doubt that it is
> self-compiling: unless we have the source, we can't know for sure.
TMA (abandoned) mimics A86 somewhat, but I don't know offhand (without trying, and I'm on the wrong computer) whether it builds with A86. Also, Octasm was originally written in A86 but now (only) assembles itself.

> > Well, it's still a derivative.
>
> The kernel still is. But what if I get to a point where I've rewritten
> everything? Could I release it as my work? Would anyone even care to check
> the code? Probably not. (Don't misconstrue this. I don't want to steal any
> of Mike's code. Rewriting everything just really is a possibility.)
Yes, obviously I didn't mean to imply legalities. Yes, I personally think you could do whatever if you rewrite it. But I'm no lawyer (and despise legalese).

> > The next Y2K problem.
>
> Oh you. I wasn't aiming for that, 38 just is a nice number.
A lot can happen in 28 years! Looking at the past ten years, we would've never guessed computers would change so much.

> > it's pretty much "dead" legally, IMHO.
>
> Like about 95% of DOS software, only for that we don't get the source at
> all. So it was pretty nice of them to give us even "semi-free" source code,
> don't you think?
Yes, of course, I just hate that it has a license which apparently "sucks", but nobody is around to change it or even discuss it officially.

> They're Linux zealots. They can't accept that there might be cases were
> accepting binaries instead of recompiling everything might be better, even
> if these binaries are just for a deprecated, foreign architecture no one
> supports.
It's such a bullcrap pretext. They have binary blobs, yet somehow FreeDOS is tainted?? Humbug. 99% of Linux distros aren't even FSF-labeled "free".

> Solution: Change people. Or use a workaround, for example, provide a
> free-free-free compiler for them. (Extend gcc? Use some existing DOS
> compiler with GPL or a really free license?)
Some of the kernel devs probably knows more here than me what would need to be done. I don't honestly even remember what memory model the kernel uses. In theory, we could probably easily convert it from (non-portable) C to (non-portable) assembly for NASM, I guess. WDIS is our friend. ;-)

BCC/Dev86 is a pain to compile, so that doesn't help either. And it's pretty much the only GPL 16-bit C compiler that I know of.

> > And no, VFAT isn't in FreeDOS proper,
> > so that can't be a good reason against it.)
>
> VFAT is in Linux, so what?
No, I think they removed it after the TomTom incident. Last I heard, they only write the LFN, not the SFN now, but I haven't tested. (Such a dumb patent, esp. since it was for FAT, which MS hates and deprecates anyways.)

> Seems somewhat extreme. As pedant, I believe a one-pass compiler wouldn't
> be better than a multi-pass one. Maybe bad OW configuration (use "-os" or
> so to optimize for size)? There might also be more/better run-time checks
> in OW.
I didn't mean it was "better", just smaller, and obviously I couldn't remember if that was before or after UPXing (apparently only after).

> > It has something to do with size, I never looked to closely. Yes, I
> know,
> > it shouldn't be an issue, but it is. Blame the lame-o C compilers.
>
> There's at least one PUSH imm opcode in one of the (NASM) source files.

Still?? I think they fixed that. What file / version are you looking at? But again, there are very few 8086 users still. I think Mike Chambers runs DR-DOS, and I told him to try a newer FreeDOS, and it might've worked. Perhaps SYS from 2038 fixed it, I don't remember.

> Given that LOADFIX is absolutely useless on true 8086 and 80186 processors
> (they only address 1024 KiB of memory, there's no HMA or A20) you selected
> a bad example ;-)
Well, the point was that they couldn't share a single shell between 100% of all users. Even if 8086 users can't use it, others can (though I never need it, honestly, and originally LOADFIX for FreeDOS was a separate util anyways, so it's no dealbreaker).

> As I said, the FreeCOM version I examined (0.84-pre XMS_Swap, 2005-07-20)
> really does have 8086-incompatible code. (Only seen it in an XMS call
> function though, and XMS doesn't exist on true 8086 machines, does it?
> Still bad enough.)
They had both XMS and KSSF/VSPAWN variants, obviously preferring the former.

Oops, forgot that SourceForge still only has 0.82pl3. (God, they are so desparate for more volunteers or really stubborn, I dunno)! 0.84 had "too much added" without review, says Eric, including an obscure bug/hang, and even Blair never updated it "yet again" like he originally claimed (swapping, oh well).

> > I haven't rebuild FreeCOM lately.
>
> Either way, fixing the broken 8086 compatibility should be a very easy
> task.
I'm not even sure it builds with OpenWatcom, I forget. I know I had some minor trouble with SUPPL, so I just used a prebuilt lib for that. It's not that complicated, but it could surely be much much easier. (Centroid's DJGPP/386 shell is less compatible to MS-DOS but a thousand times easier to build. But again there was a stupid flaw where mkdir pulls in ctime unnecessarily, bloating it by several useless kb. I never properly patched that for DJGPP two years ago, and they didn't seem to care anyways. Oh well. Too much to do! I guess I'm too useless and spastic and ambitious, sorry guys.)

> > I dunno, everything's just
> > so disorganized, too much to do, not enough volunteers, etc.
>
> I fondly regard Robert's mail asking about how FreeDOS 1.1 tasks are
> organized. And Pat's very inexplicit answer... "assessing what needs to be
> done in order to scope out the effort". Heheheheheh.
Four years (last Friday) since 1.0 release. Not a big deal, DOS ain't high priority. But yeah, we could use a bit better organization and a few volunteers. ;-) I still say we should (also) focus on DOS emulation, which is "teh futurez!"
ecm

Homepage E-mail

Düsseldorf, Germany,
08.09.2010, 20:30

@ Rugxulo
 

NASM version 2.09 available | A86 and kernels

Post reply

> > > But yeah, it hasn't been developed since 2000, [...]
> >
> > That really doesn't bother me.
>
> Nor me, but it just means he hasn't kept it up.
Which wouldn't matter to me if it was as sophisticated as NASM or more so to begin with.

> Granted, I personally can't
> help but wonder if we've "jumped the shark" on x86, adding so many things
> (SSSE3, SSE4.1, XOP, AVX) in addition to obvious things like FPU, MMX,
> SSE2, AMD64.
It's what works with the market right now. Ask the next Itanium-based PC you see.

> Yes, obviously I didn't mean to imply legalities.
I don't see why the term "derivative" mentioned by you would apply otherwise in this context, but oh well. Probably just because that's what's on my mind right now.

> Looking at the past ten years, we would've
> never guessed computers would change so much.
But what about their evolution from 1990 to 2000? The decade before that? Computers always changed much. I'm used to it. The only thing that might have been surprising was the internet's development, although that took off in the 90ies too.

> Yes, of course, I just hate that it has a license which apparently "sucks",
> but nobody is around to change it or even discuss it officially.
Better than with DRDOS, Inc where they have refused to provide EDR-DOS with a freer license. (That they tried to sell trash made of stolen software is an entirely different story.)

> 99% of Linux distros aren't even FSF-labeled "free".
FSF isn't even what I would label "free". I don't want to primarily produce free software for its own purpose (at least, not currently). Strategically making available certain projects only with Copyleft is acceptable, and this Copylefted part of a popular distribution of course needs to be massive enough to avoid it being "stolen" for closed-source software (with the Copylefted stuff replaced). But I don't think Copyleft really is the way to go for all software, at least not in its current implementation. (The GPL is too strict as well; I would prefer LGPL (for everything). If I were to choose a license from the FSF.) I want people to copy parts of my program if it helps make their software better - no matter what license they (have to) use.

> Some of the kernel devs probably knows more here than me what would need to
> be done.
On gcc? Add 16-bit support and OMF object/.EXE/.COM output, he. On TFK? Probably not much, I assume it's portable enough that adding support for another compiler (gcc or not) wouldn't be too hard.

> I don't honestly even remember what memory model the kernel uses.
Memory models are enframing. They don't exist. Seriously: That doesn't matter much. Unless your compiler doesn't support far pointers at all you can do everything. I don't know of any compiler that does all of the (sophisticated) relocation required for a kernel, so you need to do some things on your own anyway.

> In theory, we could probably easily convert it from (non-portable) C to
> (non-portable) assembly for NASM, I guess. WDIS is our friend. ;-)
Shush, interest in kernel development is little enough as it is.

> No, I think they removed it after the TomTom incident. Last I heard, they
> only write the LFN, not the SFN now, but I haven't tested.
I think that was left as an option that defaults to off, for now.

> I didn't mean it was "better", just smaller, [...]
As the pedant I am, I have to note that you are right: TC is smaller. Its output is not :-P

(I meant "produces smaller output" with "better" here.)

> [...] and originally LOADFIX for FreeDOS was a separate util anyways, [...]
LOADFIX is easier to implement in the shell because you don't have to hook the program loading or termination explicitly.

> 0.84 had "too
> much added" without review, says Eric, including an obscure bug/hang, and
> even Blair never updated it "yet again" like he originally claimed
> (swapping, oh well).
So yeah...

> But yeah, we could use a bit better organization
What organization?

> I still say we should (also) focus on DOS emulation,
> which is "teh futurez!"
I say someone should make a serious fork of DOSBox which makes its CPU, BIOS and DOS compatible properly, or just replaces the latter with a host file system redirector driver done right. An interface to load and access host modules (.DLL or equivalent dynamic libraries) should be provided too. They should also care for bugs and issues that don't affect any specific DOS games.

dosemu might be a better base looking at its features, but I don't think it would be easy to port that to operating systems other than Linux and/or architectures other than x86 or AMD64. (Not a big problem now, but might become one. (That is, if PCs switch to another architecture before they're powerful enough to fully emulate a current x86 machine.))

---
l
ecm

Homepage E-mail

Düsseldorf, Germany,
11.09.2010, 12:27

@ Rugxulo
 

NASM version 2.09 available | A86 and kernels

Post reply

> > They're Linux zealots. They can't accept that there might be cases were
> > accepting binaries instead of recompiling everything might be better,
> even
> > if these binaries are just for a deprecated, foreign architecture no one
> > supports.
>
> It's such a bullcrap pretext. They have binary blobs, yet somehow FreeDOS
> is tainted?? Humbug. 99% of Linux distros aren't even FSF-labeled "free".
I don't know about binary blobs, but the Debian Free Software Guidelines say this, which might be the reason they want free compilers:

DFSG> To be free, software must be modifiable by [anyone, and they] must
DFSG> also be able to legally share modifications [...]

This probably means they want their users able to recompile everything, only using the (free) compilers that are included in the distribution.

---
l
Rugxulo

Homepage

Usono,
11.09.2010, 23:44

@ ecm
 

Debian/OW ... FASM

Post reply

> I don't know about binary blobs, but the
> Debian
> Free Software Guidelines say this, which might be the reason they
> want free compilers:
>
> DFSG> To be free, software must be modifiable by [anyone, and they] must
> DFSG> also be able to legally share modifications [...]
>
> This probably means they want their users able to recompile everything,
> only using the (free) compilers that are included in the distribution.
Sure, that's the reason, but it's bogus. They don't want to rebuild FreeDOS, they don't care and never have. They also couldn't care about DOSEMU either. So why pretend? Sure, OW has a weirdo license, but nobody is going to update it any time soon. If the OW hackers (who've spent years on the thing) don't care about worrying over their own work, why should I? Bah, such a mess, even if OSI approved (heh). The real problem is that nothing else (more free) can build FreeDOS, so beggars can't be choosers.

P.S. I personally think FASM is plenty free. Sure, you can't GPL it, but you couldn't realistically do that anyways with other licenses (except as a whole, which really only affects your own changes). Besides, nobody needs or wants to do so with FASM, and it's already been used commercially in many places, so it's "moot". I guess it's more of a "don't pretend you wrote it" clause than anything, so people can not be confused by different licensed derivatives. (And Japheth is right, it lacks OMF, but so does DJGPP. Besides, there are already tons of existing tools that handle that, so adding it to FASM wouldn't hurt but isn't a priority.)

---
Know your limits.h
ecm

Homepage E-mail

Düsseldorf, Germany,
12.09.2010, 02:40

@ Rugxulo
 

Debian/OW ... FASM

Post reply

> Sure, that's the reason, but it's bogus. [Blah]
It's bogus if you look at it from a practical viewpoint. It's not if you understand that it's a political/philosophical reason. (And though I understand them that way, I don't share their opinion.)

> Bah, such a mess, even if OSI approved (heh).
That's the fundamental difference between OSI and FSF.

> The real problem is that nothing else (more free) can build FreeDOS,
> so beggars can't be choosers.
It's Write-your-own-compiler day! If anyone cares enough about Debian.

> P.S. I personally think FASM is plenty free.
It's free - even as far as the FSF is concerned - but it's more restrictive than the actual (2- or 3-clause) BSD license. It's also a practical disadvantage to re-use the text of some other license then append a sloppy Copyleft restriction to that, this just confuses people more than an entirely (or at least, obviously visibly) custom license would have. (I won't dare suggesting to just use the GPL if you want Copyleft, heh. Ridiculous, what!)

> Sure, you can't GPL it, but
> you couldn't realistically do that anyways with other licenses (except as a
> whole, which really only affects your own changes).
What? You can GPL any 2- or 3-clause BSD licensed program all you like. (Sure, it's misconduct, but you're legally allowed to.) I don't understand what you say inside the parentheses at all.

> Besides, nobody
> needs or wants to do so with FASM, and it's already been used commercially
> in many places, so it's "moot".
It's partly a question of your philosophy (i.e. the source code is free and its freedom is "defended" (Copyleft), or the user is free), but then it's also that I feel cheated reading a 2-clause BSD license and then some lazy Copyleft notice. It's like the Sybase license thing all over again.

I also don't know why Tomasz detests the (L)GPL (alternatively, with a linking exception) like that.

> I guess it's more of a "don't pretend you wrote it" clause than anything,
> so people can not be confused by different licensed derivatives.
Why? All derivatives of BSD licensed software need to reproduce the copyright notice in the source code, documentation and other material anyway.

> And Japheth is right, it lacks OMF, but so does DJGPP.
DJGPP is a toolchain primarily intended for C development of 32-bit DPMI programs. FASM is an assembler that ostensibly supports 16-bit DOS targets. Do you see the difference? (Yes, there's an OMF 32-bit format but you don't need that for DPMI development with DJGPP because DJGPP gives you the whole toolchain for COFF anyway and 32-bit OMF isn't that widely used.)

> Besides, there are already tons of existing tools that handle that,
> so adding it to FASM wouldn't hurt but isn't a priority.
Particularly, you cannot link 16-bit DOS programs consisting of separate modules (possible created by different assemblers or compilers) with any FASM source code because the OMF format is just the 16-bit DOS object format. I mean, come on. Acceptable OMF support is even implemented in NASM, and it's so free you can just copy or adapt its code (even for "proprietary" Copyleft licensed software such as FASM).

(Okay, please just tell me you did not say the "tons of existing tools" are the reason OMF doesn't have priority for 16-bit DOS support. Because if you did say so, I would have to answer that precisely they are the reason OMF does have some priority for 16-bit DOS support.)

---
l
Rugxulo

Homepage

Usono,
12.09.2010, 04:18

@ ecm
 

Debian/OW ... FASM

Post reply

> > The real problem is that nothing else (more free) can build FreeDOS,
> > so beggars can't be choosers.
>
> It's Write-your-own-compiler day! If anyone cares enough about Debian.
Too hard to do, esp. since 16-bit is considered obsolete by Linux, Win32, *BSD. Heck, people are starting to say 32-bit is deprecated (eh??), as if 64-bit must kill everything else in order to justify itself (lame).

> What? You can GPL any 2- or 3-clause BSD licensed program all you like.
> (Sure, it's misconduct, but you're legally allowed to.)

How can you require someone to submit their changes without you having changed any of the code itself? I mean legally, you really think that's possible? I think you can only optionally license your own additions as GPL, which means the whole must be "GPL-compatible", right? The original bits would still remain as-is.

> > Besides, nobody
> > needs or wants to do so with FASM, and it's already been used
> commercially
> > in many places, so it's "moot".
>
> It's partly a question of your philosophy (i.e. the source code is free and
> its freedom is "defended" (Copyleft), or the user is free), but then it's
> also that I feel cheated reading a 2-clause BSD license and then some lazy
> Copyleft notice. It's like the Sybase license thing all over again.
The Sybase license is much more confusing and worse, by far.

> > I guess it's more of a "don't pretend you wrote it" clause than
> anything,
> > so people can not be confused by different licensed derivatives.
>
> Why? All derivatives of BSD licensed software need to reproduce the
> copyright notice in the source code, documentation and other material
> anyway.
But if he doesn't prevent people from not sharing their modifications, I guess he doesn't want anybody else forcing that upon them either.

> > And Japheth is right, it lacks OMF, but so does DJGPP.
>
> DJGPP is a toolchain primarily intended for C development of 32-bit DPMI
> programs. FASM is an assembler that ostensibly supports 16-bit DOS targets.
FASM is a 32-bit assembler and only runs on 32-bit, not 16-bit. It assembles itself without needing to use a linker, and in most cases it avoids such. I think only as an afterthought did Tomasz even add linkable object support. So he personally doesn't need it, so he hasn't implemented it.

> Do you see the difference? (Yes, there's an OMF 32-bit format but you don't
> need that for DPMI development with DJGPP because DJGPP gives you the whole
> toolchain for COFF anyway and 32-bit OMF isn't that widely used.)
32-bit OMF is still used somewhat (Digital Mars, OpenWatcom) but didn't Borland and MS handle it differently? So it's quite complex, which makes implementing it that much harder.

DJGPP only uses COFF in lieu of (older) a.out, esp. since GNU ld (Binutils) already had support for it. GCC and pals are heavily *nix-oriented, which means OMF isn't important to them since it's only used on x86.

> > Besides, there are already tons of existing tools that handle that,
> > so adding it to FASM wouldn't hurt but isn't a priority.
>
> Particularly, you cannot link 16-bit DOS programs consisting of
> separate modules (possible created by different assemblers or
> compilers) with any FASM source code because the OMF format is just
> the 16-bit DOS object format.

Right, because FASM wasn't designed that way, the author is only one person, he'd rather focus on other features. Plus OMF is complex, not trivial, so even if he wanted, it would take quite a while to shake out the bugs, and there truly isn't enough interest in OMF these days.

> I mean, come on. Acceptable OMF
> support is even implemented in NASM, and it's so free you can just copy or
> adapt its code (even for "proprietary" Copyleft licensed software such as
> FASM).
NASM 2.07 was first to be BSD-licensed, and it's not that old, so FASM couldn't verbatim (well, you know what I mean) borrow from it anyways until then, esp. since Tomasz prefers pure x86 assembly in lieu of C.

> (Okay, please just tell me you did not say the "tons of existing
> tools" are the reason OMF doesn't have priority for 16-bit DOS support.
It doesn't have priority to FASM's author because NASM, ArrowASM, LZASM, WASM, JWASM, Wolfware w/ macros, TASM, MASM, A86, Optasm?, etc. etc. all already support it.

> Because if you did say so, I would have to answer that precisely they
> are the reason OMF does have some priority for 16-bit DOS support.)
16-bit isn't cool anymore, so nobody cares. :-(
ecm

Homepage E-mail

Düsseldorf, Germany,
12.09.2010, 14:29

@ Rugxulo
 

Debian/OW ... FASM

Post reply

> How can you require someone to submit their changes without you having
> changed any of the code itself? I mean legally, you really think that's
> possible? I think you can only optionally license your own additions as
> GPL, which means the whole must be "GPL-compatible", right? The original
> bits would still remain as-is.
No. Although you cannot change the license used by the original project (f.e. official NASM build), you can pretty much copy all their code, then license that fork as GPL. This means anyone who would then obtain their code from your fork would have to use the GPL, but anyone who got the official NASM build still would get it under their license.

The "you need to modify it" part is moot, if not generally, then because of this: I take all the NASM source code. I change file A to include 3 lines of code it did not have. I license the fork as GPL. I change file A to remove the 3 new lines. So even if anyone insisted I need to change some of the code, there's a simple workaround for that. (There are licenses that say you ain't allowed to redistribute a program with the same source code as the official build with a different license or at all, preventing this workaround. These licenses are not considered free by the FSF.)

Besides, you have to change 50+ of NASM's source files to include a different license header anyway so that's already some work there. :-D

> The Sybase license is much more confusing and worse, by far.
True, but I still don't like the FASM license.

> But if he doesn't prevent people from not sharing their modifications, I
> guess he doesn't want anybody else forcing that upon them either.
The GPL allows you not to distribute modifications, you just mustn't distribute the binaries either. That is, anyone who gets one of your binaries (from you or someone else) has the right to get the (modified) source, but no one else.

But I see there is a valid difference here.

(Besides, you might argue that FASM's Copyleft is weak because it is not stated that combining stuff with the FASM code means that this other stuff has to be made available.)

> FASM is a 32-bit assembler and only runs on 32-bit, not 16-bit. [Blah]
Yes, I know. That's why I said "ostensibly". And "targets".

> NASM 2.07 was first to be BSD-licensed, and it's not that old, so FASM
> couldn't verbatim (well, you know what I mean) borrow from it anyways until
> then, esp. since Tomasz prefers pure x86 assembly in lieu of C.
* It was available as of the 2009-07-06 release (2.07rc1) or earlier.
* Since he would rewrite everything anyway, he could have just read their (LGPL) code or asked someone to do that to compile a documentation of the format, then implement that in FASM. This is of course moot now that the code is free.

> It doesn't have priority to FASM's author because NASM, ArrowASM, LZASM,
> WASM, JWASM, Wolfware w/ macros, TASM, MASM, A86, Optasm?, etc. etc. all
> already support it.
But that would mean these assemblers are better for some tasks than FASM. Heheheheh.

---
l
Rugxulo

Homepage

Usono,
12.09.2010, 22:18

@ ecm
 

FASM's license

Post reply

> No. Although you cannot change the license used by the original
> project (f.e. official NASM build), you can pretty much copy all
> their code, then license that fork as GPL.
I don't think so. Well, even for public domain, how could you? Their code is their code, their (original) copyright. I'm not saying I'd care or complain, but it seems backwards to re-license something you didn't write. That code should remain under the same license, it's only being compatible for the rest of the project that's legally important.

> This means anyone who would then
> obtain their code from your fork would have to use the GPL,
> but anyone who got the official NASM build still would get it under their
> license.
I doubt it. Besides, BSD vs. GPL ... GPL loves BSD, but BSD hates GPL, so nobody would prefer GPL except diehards, esp. if it was only blindly re-licensed and not by original authors / copyright holders. (Honestly I wonder why anybody cares AT ALL about stupid licenses, they are so boring! Code is code, why is it so hard for people to share and accept?)

> The "you need to modify it" part is moot, if not generally, then because of
> this: I take all the NASM source code. I change file A to include 3 lines
> of code it did not have. I license the fork as GPL. I change file A to
> remove the 3 new lines. So even if anyone insisted I need to change some of
> the code, there's a simple workaround for that.

I don't think that would count. Even though in theory you should be able to extract the original, in practice it's not always easy. But they could always just get the original anyways, assuming they knew that it existed (and where to grab it).

EDIT: I think GCC will allegedly accept 20 lines or less without copyright assignment but nothing greater.

> (There are licenses that
> say you ain't allowed to redistribute a program with the same source code
> as the official build with a different license or at all, preventing this
> workaround. These licenses are not considered free by the FSF.)
The FSF also dislikes clauses preventing non-commercial use, and yet I've seen a few "GPL" apps add that restriction.

> Besides, you have to change 50+ of NASM's source files to include a
> different license header anyway so that's already some work there. :-D
Well, the functionality stays the same. Truly, I honestly think (legally) you're only allowed to re-license your own changes. I think the "whole" of the project can be GPL even if 99% is BSD licensed.

(But I'm no lawyer though I'll admit I don't care what they think, they can invent any crazy idea, and it's insane to pretend I'll just comply blindly to whatever some crackpot can come up with. Different countries have different laws anyways, so there's no pleasing everybody.)

> > The Sybase license is much more confusing and worse, by far.
>
> True, but I still don't like the FASM license.
Why, because you can't re-license it (do you really want to??) or because it's "yet another" license that the world didn't need? The world doesn't truly "need" FASM, but it's a truly awesome tool, a good compliment to NASM, IMHO.

> (Besides, you might argue that FASM's Copyleft is weak because it is not
> stated that combining stuff with the FASM code means that this other stuff
> has to be made available.)
I don't think Tomasz intends to restrict anyone from doing anything with it, including proprietary changes, which would indeed not work if it was GPL. (However, AFAICT, nobody has made any sizable changes to it except for Fresh, FASMARM, Wink ... and you can easily live without any of that).

> > FASM is a 32-bit assembler and only runs on 32-bit, not 16-bit. [Blah]
>
> Yes, I know. That's why I said "ostensibly". And "targets".
In other words, 32-bit was the initial mindset, even if he did / does love DOS and DOS Navigator heavily.

> > NASM 2.07 was first to be BSD-licensed, and it's not that old, so FASM
> > couldn't verbatim (well, you know what I mean) borrow from it anyways
> until
> > then, esp. since Tomasz prefers pure x86 assembly in lieu of C.
>
> * It was available as of the 2009-07-06 release (2.07rc1) or earlier.
> * Since he would rewrite everything anyway, he could have just read their
> (LGPL) code or asked someone to do that to compile a documentation of the
> format, then implement that in FASM. This is of course moot now that the
> code is free.
Honestly, I think he has looked at NASM before, but obviously he's rewritten everything to suit his own ways of doing things (different macros, always did opcode size reduction similar to YASM, different algorithms).

> > It doesn't have priority to FASM's author because NASM, ArrowASM, LZASM,
> > WASM, JWASM, Wolfware w/ macros, TASM, MASM, A86, Optasm?, etc. etc. all
> > already support it.
>
> But that would mean these assemblers are better for some tasks than FASM.
> Heheheheh.
Yes, of course, since there are too many object and executable formats out there, and no one assembler or linker supports them all (though NASM tries pretty hard). Clearly Tomasz has no problem writing apps (DOS, Win32, Linux) completely in pure assembly. It shouldn't be that surprising. ;-)
ecm

Homepage E-mail

Düsseldorf, Germany,
12.09.2010, 23:12

@ Rugxulo
 

FASM's license

Post reply

> I don't think so. Well, even for public domain, how could you? Their code
> is their code, their (original) copyright.
But they allow you to redistribute and modify it as you wish. As for Public Domain (which isn't exactly the same as 2-clause BSD): that would mean no copyright applies, so you're free to do everything you want with it, even some things (i.e. removing the copyright/origin statements) you ain't allowed with any BSD license.

> I'm not saying I'd care or
> complain, but it seems backwards to re-license something you didn't write.
> That code should remain under the same license, it's only being compatible
> for the rest of the project that's legally important.
The point was that it's allowed. If that is the case, it doesn't mean it makes sense!

> I doubt it. Besides, BSD vs. GPL ... GPL loves BSD, but BSD hates GPL, so
> nobody would prefer GPL except diehards, esp. if it was only blindly
> re-licensed and not by original authors / copyright holders.
That's why I mentioned it in the example - although there's no Copyleft with the BSD licenses, you still can't "revoke" the freedom users get from other (here: the original) distributors.

Besides, it's the other way around: BSD loves everyone, and it allows everyone to copy the program under whatever license. GPL is a lot more picky ;-)

> (Honestly I
> wonder why anybody cares AT ALL about stupid licenses, they are so boring!
> Code is code, why is it so hard for people to share and accept?)
's what I say. It's also the reason I prefer (2-clause) BSD for the stuff I write - everyone should be happy to use it instead of worrying about their license, whether they're in a business or FSF zealots. I don't like the GPL's viral nature, so I won't spread it more if I have the choice not to.

Of course, choosing BSD for my stuff also has the practical advantage that I can switch to GPL whenever I feel like it, even if others have contributed to my (BSD) code base. Not that I anticipate that to happen. (Me feeling like changing to GPL, or contribution to my code base, you ask? Probably both.)

> Even though in theory you should be able to extract the original, in
> practice it's not always easy.
What? That example was to show how to work around your "need to change something"; I would specifically create a fork to carry that out, not use some existing one.

> But they could
> always just get the original anyways, assuming they knew that it existed
As I said, that's what the point of this whole exercise was. You certainly can redistribute a fork of a (2-/3-clause) BSD project under the GPL, but unless you improved it so much that people had a reason to prefer your fork, they wouldn't have to prefer it.

> EDIT: I think GCC will allegedly accept 20 lines or less without copyright
> assignment but nothing greater.
Really? That would be ridiculous, especially from the GNU zealots that talk about freedom all the time. If I want to write a source code file without any copyright notices, free tools should allow me to do that! (It's also a question of privacy - the tools should not scan my data for such things at all.)

> The FSF also dislikes clauses preventing commercial use, and yet I've
> seen a few "GPL" apps add that restriction.
Yep, thus are people. Legally, these applications of course ain't compatible with the GPL, they (so to say) use a non-GPL license based on the GPL.

> Truly, I honestly think (legally)
> you're only allowed to re-license your own changes.
No. Whether re-licensing work you don't "own" is ethical is an entirely different question - but I'm pretty sure it's legal. IANAL either, so we would have to ask, like, the FSF for a more definitive answer.

> I think the "whole" of
> the project can be GPL even if 99% is BSD licensed.
That is true, but only if you keep track of what is available as BSD and what is not and if you inform the receiver (ie user) about the fact that these parts are still available under BSD. Otherwise, they ain't allowed to "extract" the BSD code again, even if they know which parts these are. (Practically, if they know that although the whole project is exclusively licensed as GPL now, they'll usually have access to the original code anyway so it doesn't matter.)

> But I'm no lawyer though I'll admit I don't care what they think, they can
> invent any crazy idea, and it's insane to pretend I'll just comply blindly
> to whatever some crackpot can come up with.
The BSD and GPL licenses make perfect sense to me.

> Why, because you can't re-license it
Because it's less free. NASM is freer. That's where we started, remember?

> (do you really want to??)
No.

> or because it's "yet another" license that the world didn't need?
Yes, that too.

> The world doesn't truly "need" FASM,
Quoting that out of context might not AMUSE some :-P

> but it's a truly awesome tool, a good compliment to NASM, IMHO.
I don't know. True, there's a few things that FASM can do but NASM can not. NASM, in turn, is freer and more portable.

> I don't think Tomasz intends to restrict anyone from doing anything with
> it, including proprietary changes, which would indeed not work if it was
> GPL.
Is proprietary adaptation really allowed by that license? It says not to redistribute FASM code under any other license. Although it has the loophole that you can distribute only binaries (i.e. make the code base proprietary), you still would have to use the FASM license for your source. That means you wouldn't be allowed to combine the source with any other source code that has a license conflicting with FASM's. (For example, suppose there is a program FOO which has a license very similar to FASM's. Now you wouldn't be allowed to combine FOO's and FASM's source code, because both require all source code to use their license.) This is a practical problem, because no company would risk to violate the license like that even though arguably it would be hard to prove from the outside (when they only distribute binaries).

True, the GPL doesn't allow proprietary adaptation, but I don't think FASM's license does either. Whether that's intentional I don't know.

> Honestly, I think he has looked at NASM before, but obviously he's
> rewritten everything to suit his own ways of doing things (different
> macros, always did opcode size reduction similar to YASM, different
> algorithms).
The point was that he could now (and even before) implement OMF support by using NASM's low-level implementation as reference. Assembler syntax doesn't come into this.

---
l
Rugxulo

Homepage

Usono,
13.09.2010, 01:49

@ ecm
 

FASM's license

Post reply

> > EDIT: I think GCC will allegedly accept 20 lines or less without
> copyright
> > assignment but nothing greater.
>
> Really? That would be ridiculous, especially from the GNU zealots that talk
> about freedom all the time. If I want to write a source code file without
> any copyright notices, free tools should allow me to do that! (It's also a
> question of privacy - the tools should not scan my data for such things at
> all.)
Sorry, didn't mean to confuse you. No, I meant the GCC devs (on behalf of FSF?) won't accept any contributions to the compiler itself without copyright attribution, but I think they don't need it for trivial code that is 20 lines or less.

> > But I'm no lawyer though I'll admit I don't care what they think, they
> can
> > invent any crazy idea, and it's insane to pretend I'll just comply
> blindly
> > to whatever some crackpot can come up with.
>
> The BSD and GPL licenses make perfect sense to me.
I meant lawyers and their crazy (constantly changing and new) laws. There's no way to please them across the board. It's just insane to pretend I can even understand their ideas, much less would be willing to comply (at a loss) at every random decision they make. I'm not trying to be a bastard, but they can't just say whatever they want and get away with it.

> > The world doesn't truly "need" FASM,
>
> Quoting that out of context might not AMUSE some :-P
Well, let's be honest, how many assemblers does one person need? I can name at least 30 for x86, and that's surely more than I need! I could maybe live exclusively off of NASM, YASM, FASM, JWASM, or OCTASM if I had to. Some people seem to only use GAS (blech). Well, okay, it truly depends on OS and compiler support that my projects use, etc, but you get the idea: there are (too) many! Doesn't mean somebody can't write yet another with some innovative ideas (like OCTASM or SolarASM or even FASM did).

> > but it's a truly awesome tool, a good compliment to NASM, IMHO.
>
> I don't know. True, there's a few things that FASM can do but NASM can not.
> NASM, in turn, is freer and more portable.
NASM is cool, but it has few true advantages over FASM, esp. for my needs. Then again, I'm just a hobbyist, just a lame hacker. I do like both a lot, though, truly.

> > I don't think Tomasz intends to restrict anyone from doing anything with
> > it, including proprietary changes, which would indeed not work if it was
> > GPL.
>
> Is proprietary adaptation really allowed by that license? It says not to
> redistribute FASM code under any other license. Although it has the
> loophole that you can distribute only binaries (i.e. make the code base
> proprietary), you still would have to use the FASM license for your source.
> That means you wouldn't be allowed to combine the source with any other
> source code that has a license conflicting with FASM's. (For example,
> suppose there is a program FOO which has a license very similar to FASM's.
> Now you wouldn't be allowed to combine FOO's and FASM's source code,
> because both require all source code to use their license.) This
> is a practical problem, because no company would risk to violate the
> license like that even though arguably it would be hard to prove from the
> outside (when they only distribute binaries).
>
> True, the GPL doesn't allow proprietary adaptation, but I don't think
> FASM's license does either. Whether that's intentional I don't know.
To be honest, I'm not sure, but he said something recently that sounded like he didn't care what somebody did with their changes (e.g. Wink). Plus there's the (recently updated) FASM DLL, which makes it even easier to use in proprietary apps. (I think PureBASIC just uses the FASM.EXE directly, though.)

> > Honestly, I think he has looked at NASM before, but obviously he's
> > rewritten everything to suit his own ways of doing things (different
> > macros, always did opcode size reduction similar to YASM, different
> > algorithms).
>
> The point was that he could now (and even before) implement OMF support by
> using NASM's low-level implementation as reference. Assembler syntax
> doesn't come into this.
He's already said it's pretty complex to do correctly, and it's clearly low priority as he was quite busy with real life (PhD?) for a long time. Also, like I said, there are other assemblers who already do it, hence probably why GAS and YASM also still don't support it. Face it, old closed source 16-bit OBJ libs are rare these days, esp. considering how far Linux and *BSD have come pretty much reimplementing everything from scratch. (But honestly, he is going to implement Mach-O support soon, so I guess adding yet another format isn't too far from his mind.)
ecm

Homepage E-mail

Düsseldorf, Germany,
13.09.2010, 14:13

@ Rugxulo
 

FASM's license

Post reply

> Sorry, didn't mean to confuse you. No, I meant the GCC devs (on behalf of
> FSF?) won't accept any contributions to the compiler itself without
> copyright attribution,
Ah, thanks, that makes more sense. I thought the alternative would be silly even for GNU.

> Well, let's be honest, how many assemblers does one person need? I can name
> at least 30 for x86, and that's surely more than I need! I could maybe live
> exclusively off of NASM, YASM, FASM, JWASM, or OCTASM if I had to. Some
> people seem to only use GAS (blech). Well, okay, it truly depends on OS and
> compiler support that my projects use, etc, but you get the idea: there are
> (too) many! Doesn't mean somebody can't write yet another with some
> innovative ideas (like OCTASM or SolarASM or even FASM did).
I would prefer implementing stuff in the existing open-source assemblers though - NASM, FASM, JWASM, depending on your syntax preference. YASM isn't really needed either any more, because the reason it was created was reversed by the free NASM releases (there are some parts of YASM not available under 2- or 3-clause BSD), though it does provide better support for debugging formats and has a GAS syntax parser. (They also say it's more modular, but nothing has come of that yet.)

What innovative ideas are OCTASM and SolarASM made of? I think I heard of SolarASM once but besides that I don't know either of them.

> I do like both a lot, though, truly.
It cannot be! You must decide! :-D

> He's already said it's pretty complex to do correctly,
NASM does it well enough. Except the missing hack to make Delphi work, but that should be quite easy too.

> Face it, old closed source
> 16-bit OBJ libs are rare these days,
True, but there are still interesting programs around that are only available as object. Besides, mixing (16-bit) C or any other HLL and Assembly is done best with OMF output.

> esp. considering how far Linux and
> *BSD have come pretty much reimplementing everything from scratch.
That doesn't come into 16-bit programming much though.

---
l
Rugxulo

Homepage

Usono,
13.09.2010, 22:27

@ ecm
 

FASM's license

Post reply

> I would prefer implementing stuff in the existing open-source assemblers
> though - NASM, FASM, JWASM, depending on your syntax preference.

Herbert Kleebauer wrote his own but then (for portability?) wrote some fancy NASM macros to emulate it. Very weird 68000-ish syntax. And I think he did things the hard way for one example by writing an ELF executable from scratch! (The things people do to avoid linkers, heh.)

> What innovative ideas are OCTASM and SolarASM made of? I think I heard of
> SolarASM once but besides that I don't know either of them.
OCTASM is just different syntax, esp. multiple instructions on one line. It runs on OctaOS and DOS. The DOS version can be grabbed here while you'll have to get latest OctaOS from Sac.sk (for some reason, I guess he abandoned his Google Pages / Site, I haven't heard from him lately). It's public domain, I think, and assembles itself. (BTW, OctaOS also includes FASM.) Well, truly it only supports flat binary output, but it can link ELF somewhat.

SolarASM was an afterthought, Bogdan was originally writing with TASM using HLL constructs, so it emulates that. Of course, he at first GPL'd the OS, then closed it, opened it, closed it again, and now it's still closed (but barely updated?). Meh. It runs FASM too, allegedly. Anyways, I think SolarASM can run on Win32 also, and it produces output for various formats. Honestly, I haven't messed with it too much, but it definitely seemed interesting. (Well, they're all interesting to me, heh.) Read about it here.

> > I do like both a lot, though, truly.
>
> It cannot be! You must decide! :-D
None of them are perfect. Guess I might have to write my own!! ;-) j/k

> > Face it, old closed source
> > 16-bit OBJ libs are rare these days,
>
> True, but there are still interesting programs around that are only
> available as object.

Not Linux compatible? OBSOLETE! :lol:

> Besides, mixing (16-bit) C or any other HLL and
> Assembly is done best with OMF output.
 >
> > esp. considering how far Linux and
> > *BSD have come pretty much reimplementing everything from scratch.
>
> That doesn't come into 16-bit programming much though.
The point is that they can do "everything" (more or less) in 32-bit, so they don't care about 16-bit at all. What I find funny is that they hailed 32-bit so heavily, refused to even think about anything else, then 64-bit came and knocked them on their heads. Now all the arguments about "too much maintenance" are moot. If they don't support 64-bit, they aren't "kewl", so they've all rushed to that, even if most computers still have less than 4 GB. Even worse, it gives them an excuse to hate 16-bit even more.
ecm

Homepage E-mail

Düsseldorf, Germany,
14.09.2010, 15:50

@ Rugxulo
 

FASM's license

Post reply

> [...] did things the hard way for one example by writing an ELF
> executable from scratch!
Where's the problem? I'm not saying linkers ain't useful, but there are definitively cases for which (A) you don't need them or for which (B) you can't use them, usually because you require a specific executable format and data arrangement that you can't get the linker to do reliably/at all.

> OCTASM is just different syntax, esp. multiple instructions on one line.
All right, why not make Assembly language harder to understand. Come on. Most of the lines in my code have a comment anyway, why would I want to put multiple instructions on one line? It doesn't strike me as something I would want to encourage either.

> Of course, he at first GPL'd the OS,
> then closed it, opened it, closed it again, and now it's still closed (but
> barely updated?).
Ah, that sucks.

> > > Face it, old closed source
> > > 16-bit OBJ libs are rare these days,
> >
> > True, but there are still interesting programs around that are
> only
> > available as object.
>
> Not Linux compatible? OBSOLETE! :lol:
 What??? Why would you want to use Loonix!! It's made of BLOAT :crying: :clap:

> The point is that they can do "everything" (more or less) in 32-bit, so
> they don't care about 16-bit at all. What I find funny is that they hailed
> 32-bit so heavily, refused to even think about anything else, then 64-bit
> came and knocked them on their heads. Now all the arguments about "too much
> maintenance" are moot. If they don't support 64-bit, they aren't "kewl", so
> they've all rushed to that, even if most computers still have less than 4
> GB. Even worse, it gives them an excuse to hate 16-bit even more.
I think their "too much maintenance" was specifically aimed at the constraints on 16-bit programming (especially in RM/V86), which weren't re-introduced with AMD64. (In fact, I hear the calling conventions and code generation became simpler because there are more registers.) Specifying this reason for why you don't want to support multiple architectures is non-sense unless you're writing gcc or libc. All the other stuff is written in HLLs and only needs to be portable enough, which it should be anyway.

---
l
Rugxulo

Homepage

Usono,
15.09.2010, 23:29

@ ecm
 

FASM's license

Post reply

> > [...] did things the hard way for one example by writing an ELF
> > executable from scratch!
>
> Where's the problem? I'm not saying linkers ain't useful, but there are
> definitively cases for which (A) you don't need them or for which (B) you
> can't use them, usually because you require a specific executable format
> and data arrangement that you can't get the linker to do reliably/at all.
No, I was just saying that he didn't use a linker, which NASM pretty much requires for anything substantial (unlike FASM, who would apparently rather directly generate everything).

> > OCTASM is just different syntax, esp. multiple instructions on one line.
>
> All right, why not make Assembly language harder to understand. Come on.
> Most of the lines in my code have a comment anyway, why would I want to put
> multiple instructions on one line? It doesn't strike me as something I
> would want to encourage either.
Tastes vary. Besides, too many small instructions on the far left make the source file VERY long with lots of blanks at the right edge. (Surely you don't comment every single line, do you?) Also he made some shortcuts to simplify things (ax=1 ++di es=0B800h). It's really only if you like his style or just want to cram everything to be more dense, (arguably) easier to read. (Compare the FASM and Octasm versions of my improved BEFI, for instance, or just look at OctaOS' sources.)

Also check here for a small snippet. ;-)

> > Of course, he at first GPL'd the OS,
> > then closed it, opened it, closed it again, and now it's still closed
> (but
> > barely updated?).
>
> Ah, that sucks.
I forget why he got mad, but some people (including MenuetOS 32-bit) just die upon various fractures. Other projects just stagnate. Not enough interest and help and good will to go around, I guess.

> > Not Linux compatible? OBSOLETE! :lol:
> What??? Why would you want to use Loonix!! It's made of BLOAT :crying:
> :clap:
No worse than XP (1.5 GB) or Vista/7 (16-20 GB). But I do suggest you read Wirth's 1995 Plea for Lean Software article. Very good points, but severely ignored! (I need to read it again myself.) "How did he ever get real work done in less than 4096 MB of RAM???" :-D :rotfl:

> I think their "too much maintenance" was specifically aimed at the
> constraints on 16-bit programming (especially in RM/V86),

No, it's more of a "we're all for POSIX ... as long as that means Linux Linux Linux", just an excuse to refuse patches. Anything that doesn't directly support Linux or GCC (32-bit/64-bit) or their political agenda is verboten.

> which weren't
> re-introduced with AMD64. (In fact, I hear the calling conventions and code
> generation became simpler because there are more registers.)

Somewhat yes, but it wasn't that hard before! It's not like they forgot how they did it all these years. Besides, how hard can it be to just save/restore registers across calls? Not very.

> Specifying
> this reason for why you don't want to support multiple architectures is
> non-sense unless you're writing gcc or libc. All the other stuff is written
> in HLLs and only needs to be portable enough, which it should be anyway.
"Should be", yeah, but never are. 32-bit assumptions, POSIX 2008, everything-is-*nix, etc. I guess you know it's an uphill battle for anybody else. The only reason non-*nix (i.e. Windows) gets anything is extreme popularity. (Well, Win32-only programming is also rampant.)

We need to work hard to avoid such assumptions, esp. that all the world runs one of the "big three" (Mac, Win, Lin). DOS386, this is why emulators are important. Even if x86 isn't available, we can still run DOS (via QEMU or VirtualBox or BOCHS or DOSBox, etc). Face it, DOS is (or was) widespread, lots of good software, but it is (sadly?) tied very strongly to x86 exclusively. Though we shouldn't let any of that prevent us from writing portable programs for future use (when appropriate, I know sometimes it's less critical, esp. if the software has no use elsewhere, relates to DOS only).
ecm

Homepage E-mail

Düsseldorf, Germany,
16.09.2010, 00:03

@ Rugxulo
 

FASM's license

Post reply

> Tastes vary. Besides, too many small instructions on the far left make the
> source file VERY long with lots of blanks at the right edge. (Surely you
> don't comment every single line, do you?)
No, but I consider a "blank" right edge easier to read. I also insert blank lines to separate blocks of instructions that belong together. (Though the block size is usually > 5 instructions.)

> Also he made some shortcuts to
> simplify things (ax=1 ++di es=0B800h). It's really only if you like his
> style or just want to cram everything to be more dense, (arguably) easier
> to read.
        mov ax, 1
        inc di
        push 0B800h
        pop es

Is this what the above code would produce? I don't see such a shortening as better at all: "inc" is defined to affect flags, whereas with "++di" it's implicit; assuming my translation is correct. If the "compiler" works around this by using another instruction or saving the flags or remembering which instructions affected the flags, it arguably creates non-optimal code or does too much of its work behind the user's back. (Also I know that push imm is 186+ yeah.)

> Somewhat yes, but it wasn't that hard before! It's not like they
> forgot how they did it all these years. Besides, how hard can it be to just
> save/restore registers across calls? Not very.
Think 16 bit.

> "Should be", yeah, but never are. 32-bit assumptions, POSIX 2008,
> everything-is-*nix, etc.
Most of that should be possible to be worked around by the compiler - even if generating 16-bit code. The only problem is probably code size - can't fit no POSIX-compatible system in 1 MiB.

> Face it, DOS is (or was) widespread, lots of good software,
What? Yes, there was good software, but there was a lot of crap too. I relate that to how widespread it was. Everyone wrote DOS programs - of course most of them were not that good.

---
l
Rugxulo

Homepage

Usono,
16.09.2010, 21:10

@ ecm
 

code density

Post reply

> > "Should be", yeah, but never are. 32-bit assumptions, POSIX 2008,
> > everything-is-*nix, etc.
>
> Most of that should be possible to be worked around by the compiler - even
> if generating 16-bit code. The only problem is probably code size - can't
> fit no POSIX-compatible system in 1 MiB.
Minix 2.0.2 was the last to truly support the 8086, and it was POSIX. I'm not saying you could or should cram everything in there, but it should be good enough for "something"! (I may be preaching to the choir here, heh.)

FYI, 2.0.4 had a bug, but it would run minimally on 286s. Minix-vmd was the 386+ fork that added virtual memory, XFree86, and GCC. Minix 3 is 386+ only but much more sophisticated, heavily becoming more modern every day (but I don't know the true minimum specs for that, can't test right now).

Niklaus Wirth worked back when they had to fit compilers in less than 64 kb. Lilith only had 256 kb of RAM, I think, and was heavily designed for code density. His Oberon system also ran in as little as 200 kb, including compiler. Of all people, I'll bet he at least thinks we've jumped the shark and lost focus on how to do things properly. You know, a megabyte truly is a lot of space. Even at worst, six bytes per instruction (8086), 1024*1024/6 = 174762, or 640*1024/6 = 109226 or more realistically 512*1024/6 = 87381. So yeah, can't we find a way to write decent programs in that many instructions??? I THINK SO!!! (I don't want to say GCC or C/C++ is an abomination, but it's truly 1000 x too complex to build and hence WAY too big in size for what it does. BTW, adjust the numbers for 10 bytes = max 286 instruction, 15 bytes max for 386.)

It's truly sloppy or crappy compilers that don't output small size anymore. Or maybe it's the dumb linkers fault for not stripping the unused parts. Still, even when some claim to be smart, it's still "too big" in my eyes. It's not that it's so horribly huge, but all that bloat does add up until you can't run anything in less than ... MB / GB. Most people don't want to go back to raw assembly, and that's fine, but we NEED decent compilers that aren't too lazy to actually do some of the grunt work. 100 kb (or more!) for a "Hello world!" (or any reasonably small program, like a dumb Befunge interpreter) is just too much. And we don't need ten billion tools that overlap and do the exact same thing but with different syntax. But whatever, simplifying and unifying everything is an art in itself, and it's not easy.

WIRTH FOR PRESIDENT 2012!
ecm

Homepage E-mail

Düsseldorf, Germany,
17.09.2010, 14:15

@ Rugxulo
 

code density

Post reply

> [...] code density. [...]
Output or input code density? :-P

> You know, a megabyte truly is
> a lot of space. Even at worst, six bytes per instruction (8086),
> 1024*1024/6 = 174762, or 640*1024/6 = 109226 or more realistically
> 512*1024/6 = 87381.
IBM's decision to reserve 384 KiB for BIOS and text/graphics buffer mapping be damned!

> It's truly sloppy or crappy compilers that don't output small size anymore.
I heard they're optimizing for speed now.

> Or maybe it's the dumb linkers fault for not stripping the unused parts.
Yes, you should strip unused parts. Think about TSRs. DOS functions Int21.31 or Int27, as utilized by most TSRs. These are stupid because a majority of TSRs don't need a PSP while installed. Most people don't care to relocate their TSR code in a way to free up all installation code either. Bonus spite if they don't even free their environment. (Besides, memory fragmentation.)

---
l
Rugxulo

Homepage

Usono,
17.09.2010, 23:06

@ ecm
 

code density

Post reply

> > [...] code density. [...]
>
> Output or input code density? :-P
Output. Wirth claims it easily was much much smaller than x86 in output code size. (Of course nowadays even he cares less since "RAM is so cheap" ... argh, I'm tired of hearing that.)

> > You know, a megabyte truly is
> > a lot of space. Even at worst, six bytes per instruction (8086),
> > 1024*1024/6 = 174762, or 640*1024/6 = 109226 or more realistically
> > 512*1024/6 = 87381.
>
> IBM's decision to reserve 384 KiB for BIOS and text/graphics buffer mapping
> be damned!
Tim Paterson's original machine(s) didn't have that limit. And rumor says IBM wanted to make it 512 kb, but MS complained. Blame bad compilers for hitting that wall so soon.

> > It's truly sloppy or crappy compilers that don't output small size
> anymore.
>
> I heard they're optimizing for speed now.
Then why is GCC so slow?? GCC is a pain to use, rebuild, etc. No way can anybody understand it all anymore, only various subsets, if even! I like GCC, but not that much! It could always be improved, slimmed down, etc.

Wirth (re)wrote a single-pass Modula-2 compiler (proper? not counting M-code interpreter?) in 5000 lines in 1984 or 1985 or so. Since it didn't need a billion separate passes due to memory limits, it was much faster and could compile itself in 45 secs. And yet even with modern machines rebuilding GCC takes ages (esp. on non-*nix, e.g. Cygwin)!! Sure assembly is mostly simple syntax and almost typeless, but I'm extremely glad it doesn't take years to build something. (Try rebuilding Menuet32 or OctaOS sometime. Even FreeDOS doesn't take nearly as long as rebuilding "modern" GCC. Old, simpler 2.7.2.3 is fast, though, primarily because things had to be fast back then. Nowadays you just throw more RAM, cores, 64-bit at it and hope it works.) Yup, we've jumped the shark.

Autoconf alone easily surpasses Wirth's compiler linecount!! Why do we need ten billion files, ten thousand defines, and a billion hacks?? Because everybody keeps adding everything and the kitchen sink: K&R, ANSI, C99, POSIX, 32-bit, 64-bit, extensions, portability, SIMD, AT&T or Intel, preprocessor, various backends, 586 and 686 and 786 optimizations, etc. etc. The source for the ACK compiler suite (pc, m2, cc) is less than 1 MB bzip2'd! Yet GM2 is like 56 MB gzip'd! Yeah, you could delete a lot of that, but similar gcc-core 4.1.2 (C only) is like 22 MB gzip'd, ugh. And gcc-core 2.95.3 was 9 MB gzip'd, if that tells you anything.

The whole Lilith machine was written in Modula-2, avoiding the need for ten million different languages and their associated tools, so it was much less complex. Of course, it was developed by a small group, not a big hodgepodge of everybody wanting to add their own stuff. Whether you like assembly or not, the advantage is that it's static, already defined, relatively simple, so you have your instructions and you make do (unlike certain HLLs which add more and more reserved words). However, obviously I dislike the idea that AVX, XOP, etc. are taking over, esp. since we're barely on the SSE4 bandwagon yet (blah), MMX and FPU are semi-obsolete, etc. (ARGH!) If all you want to do is reasonable computations, shouldn't 8086 (+ 8087) or 80386 be enough???

> > Or maybe it's the dumb linkers fault for not stripping the unused parts.
>
> Yes, you should strip unused parts. Think about TSRs. DOS functions
> Int21.31 or Int27, as utilized by most TSRs. These are stupid because a
> majority of TSRs don't need a PSP while installed. Most people don't care
> to relocate their TSR code in a way to free up all installation code
> either. Bonus spite if they don't even free their environment. (Besides,
> memory fragmentation.)
The simple truth is that "good enough" is the enemy of "better". If it's 80% good enough or covers 80% of the target audience, it's good to go. But then later someone else makes similar compromises, and now you've got 80% of 80%, and ever decreasing amount. Eventually you have one big abomination that does what nobody wants, and nobody can use it properly. Maybe this is why design by committee is so frowned upon. It's always easier to add than take away or simplify / unify everything.

Yeah, Clang / LLVM are considered "more modern" than GCC, and they are doing well, so it's not like nobody cares. (Written in C++ too. Good?? Bad??) And obviously other compilers exist. Still, the inertia of (despite everything) still making everything in C / GCC is daunting! :-/
ecm

Homepage E-mail

Düsseldorf, Germany,
18.09.2010, 02:18

@ Rugxulo
 

code density

Post reply

> > I heard they're optimizing for speed now.
>
> Then why is GCC so slow?? [rant]
Output program speed - not compiling speed, or self-compiling.

---
l
Rugxulo

Homepage

Usono,
19.09.2010, 20:23

@ ecm
 

code density

Post reply

> > > I heard they're optimizing for speed now.
> >
> > Then why is GCC so slow?? [rant]
>
> Output program speed - not compiling speed, or self-compiling.
Except that GCC compiles itself and is still slow, esp. 4.x series. So clearly it's thrashing the cache, too many separate pieces, less than optimal algorithms, suffers from complex portability, etc. Indeed it should be easier to bootstrap, IMHO. And -O0 should ideally be twice as fast as it is now. Oh well.
ecm

Homepage E-mail

Düsseldorf, Germany,
19.09.2010, 20:27

@ Rugxulo
 

code density

Post reply

Yeah I heard GCC's own source is a mess, and it can perform quite a lot optimizations. This has also lead to numerous compiling bugs with wrong output. I would prefer a slow output executable over a bogus one.

---
l
DOS386

13.10.2010, 04:17

@ ecm
 

this messy thread

Post reply

> Did you even read the linked article?
YES. It's bad.

> Now you're either just ignorant or trolling.
Nope.

> Read the article I linked. "Copyleft" is not the absence of copyright.
> Public Domain works are neither Copylefted nor copyrighted.

Until someone supplies convincing arguments proving me wrong, I'll continue to put Copyleft on my Public Domain stuff suffering from absence of Copyright.

> but the Debian Free Software Guidelines say
> the OMF format is just the 16-bit DOS object
I can live without Debian as well as without OMF, point. :-)

> Yes, I am happy with most image formats and am able to convert image formats.
Thanks :-)

> > Not Linux compatible? OBSOLETE!
> What??? Why would you want to use Loonix!! It's made of BLOAT
Right :-)

> this is why emulators are important. Even if x86 isn't available, we can still run DOS
BOCHS is sufficient. But again, this NTVDM/ DOG-BOX/DOG-EMU obsession most likely will never upgrade DOS in any of the areas where it would be most needed. Also, they won't help to convince Firefox/Opera/SumatraPDF/OpenOffice/GIMP/Audacity/... developers to release DOS versions.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Rugxulo

Homepage

Usono,
13.10.2010, 04:50

@ DOS386
 

this messy thread

Post reply

> > Read the article I linked. "Copyleft" is not the absence of copyright.
> > Public Domain works are neither Copylefted nor copyrighted.
>
> Until someone supplies convincing arguments proving me wrong, I'll continue
> to put Copyleft on my Public Domain stuff suffering from absence of
> Copyright.
http://en.wikipedia.org/wiki/Copyleft

"Copyleft is a general method for making a program (or other work) free, and requiring all modified and extended versions of the program to be free as well"
ecm

Homepage E-mail

Düsseldorf, Germany,
14.10.2010, 13:01

@ Rugxulo
 

this messy thread

Post reply

> > > Read the article I linked. "Copyleft" is not the absence of copyright.
> > > Public Domain works are neither Copylefted nor copyrighted.
> >
> > Until someone supplies convincing arguments proving me wrong, I'll
> > continue to put Copyleft on my Public Domain stuff suffering from
> > absence of Copyright.
>
> http://en.wikipedia.org/wiki/Copyleft
>
> "Copyleft is a general method for making a program (or other work) free,
> and requiring all modified and extended versions of the program to be free
> as well"
Thank you.

---
l
tom

Homepage

Germany (West),
07.09.2010, 19:58

@ Rugxulo
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> My P166 has OW 1.8 and TC++ 1.01. Both are freely available (loosely
> speaking, you pedants). For instance, BEF.C from bef-2.21.zip (Chris
> Pressey) compiles and UPXes to approx. 17k in OW but 10k in TC++. So it is
> smaller, but only because (says Tom Ehlert) that it's a "dumber" compiler
> (one-pass??).
 I NEVER said anything even remotely similar to this (and hate to be misquoted).

you might be referring to the fact that the TC kernel.sys UPXes better then the OWC kernel.sys (the TC code is still larger), where I guessed that this is probably because the TC code generator is more stupid - and as a side effect better compressable.
Rugxulo

Homepage

Usono,
08.09.2010, 06:58

@ tom
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> > My P166 has OW 1.8 and TC++ 1.01. Both are freely available (loosely
> > speaking, you pedants). For instance, BEF.C from bef-2.21.zip (Chris
> > Pressey) compiles and UPXes to approx. 17k in OW but 10k in TC++. So it
> is
> > smaller, but only because (says Tom Ehlert) that it's a "dumber"
> compiler
> > (one-pass??).
> I NEVER said anything even remotely similar to this (and hate to be
> misquoted).
Long time no see!! :-)

Sorry, I thought I paraphrased it "good enough"!

> you might be referring to the fact that the TC kernel.sys UPXes better then
> the OWC kernel.sys (the TC code is still larger), where I guessed that this
> is probably because the TC code generator is more stupid - and as a side
> effect better compressable.
Yes.

I just couldn't remember offhand if the TC code was smaller before or after UPX. I certainly didn't mean TC is "better" at codegen or output speed or anything.

---
Know your limits.h
tom

Homepage

Germany (West),
07.09.2010, 19:47

@ ecm
 

8086 is fairly useless

Post reply

> Now you could back up TC's alleged ability to produce small code.
whoever said this is fairly clueless. what version of TC by the way ?

> Do you
> have the necessary setup to compare a TC compile of TFK with an OpenWatcom
> compile?
 we compared them loooong time ago (~2001).

TC 2.01 and TCC 1.0 produce significant larger code (I remember ~20%) then OpenWatcom, even after a lot of hand-optimizing TFK for the not very much optimizing TC
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 19:55

@ tom
 

8086 is fairly useless

Post reply

> > Now you could back up TC's alleged ability to produce small code.
> whoever said this is fairly clueless.
He himself, earlier here.

> TC 2.01 and TCC 1.0 produce significant larger code (I remember ~20%) then
> OpenWatcom, even after a lot of hand-optimizing TFK for the not very much
> optimizing TC
I thought so.

---
l
Arjay

07.09.2010, 07:26

@ DOS386
 

NASM version 2.09 available | 8086 is COOOOL

Post reply

> Arjay wrote:
> > But I plan to have a test rack of some sorts again where
> > I can literally quickly test stuff with a 8086, 80186, 286, 386
> So you have 8086 and 80386 ? Would you occasionally do some tests maybe ?
 Yes, I would be happy to do occasional tests hence mention re my hardware.

> - 80486 (needs 32 MiB RAM, however)
 I can't promise that I can cover 486's particularly well as from memory the only 486 I have is a 486SX not a DX. I could probably move some RAM over...

> An 8086 DOS kernel done in pure ASM and compilable on 8086 would be very
> COOL :-)
 My own long term plans include supporting as low as 8086's where possible, obviously having a few is encouragement in itself in helping to preserve them!
ecm

Homepage E-mail

Düsseldorf, Germany,
07.09.2010, 16:30

@ DOS386
 

NASM version 2.09 available | NASM manual

Post reply

> > Besides, I'm usually with the latest daily build of NASM.
>
> TFM is still horrible, anyone cares ??? :-(
Not really, it works for me. No recent instruction list with descriptions, but given that the 8086..486 instruction set doesn't change that often any more the older manual I'm using for this is just fine.

---
l
Rugxulo

Homepage

Usono,
13.10.2010, 06:15

@ ecm
 

NASM version 2.09 available

Post reply

> > 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?
"whelp tools"

Apparently you can use "here docs" via << ... << (aka, inline texts???). Or for the compiler proper you can just put an asterisk '*' before the problem lines, and it will use a temp. env. var. if needed.

In short, I built NASM 2.09 (on XP, though) via DOS4GW OW 1.9 earlier today by making two simple changes: 1). copy NASM-2.09\lib\strlcpy.c NASM-2.09\ (dunno why this is needed, but it is), and 2). changed mkfiles\openwcom.mak to say CC=*wcl386 with the asterisk so that it can handle > 126-byte lines. (And yes I e-mailed hpa, though I doubt he cares too much, if at all.)

NASM can be built in SFNs with DJGPP and suitable C99 compiler (I think GCC 3.2.3 or newer), but they still don't ship config.h with it (even for DOS, which I recommended), and you can't (easily?) run ./configure in pure DOS, definitely not with SFNs only. (At least they finally updated CWSDPMI and bumped to a newer, less-buggy AutoConf.) I have a .BAT that works around that for 2.08.01, but I haven't updated it yet for the newer version. (The slightly-extended 0.98.38 and stock 0.98.39 built okay with CC386 back in the day, but I haven't tried newer NASM versions with it nor OrangeC.)

YASM builds with any old GCC, e.g. my one-floppy 2.95.3 package (last I checked). Not sure about OpenWatcom support.

(omitted unrelated comparison of various other assemblers' build requirements)
Japheth

Homepage

Germany (South),
14.09.2010, 15:04

@ ecm
 

8086-NASM

Post reply

>
> I today got it to compile for an 8086 DOS target after stripping the
> supported instruction set down to 686 - both executables (NASM and NDISASM)
> appear to work, but NASM.EXE is a 460 KiB file which means that it barely
> runs at all and usually crashes if I try to assemble anything at all (at
> least I hope the crash is only due to running out of memory).
Hm, a crash because it runs out of memory is not an acceptable status.

The JWasm v2.04 8086-binary does better:

- it doesn't crash when it runs out of memory, but reports a fatal error
- the binary is only 320 kB large, leaving enough space to assemble small/medium sources.
- supports instructions up to SSE3

It's here: http://www.japheth.de/Download/JWasm/JWasm204brrc3.zip

Will be a hard job to make the 8086-NASM competitive.

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
14.09.2010, 15:33

@ Japheth
 

8086-JWASM

Post reply

> Hm, a crash because it runs out of memory is not an acceptable status.
I thought so. Maybe it's related to the stack. I also had to change one define so that raa.c/h (no idea yet what they do) use smaller arrays (they were > 64 KiB), but I guess there is code that depended on the array's size. I only fiddled with it for half an hour really, didn't expect I would get it to run at all.

> Will be a hard job to make the 8086-NASM competitive.
True. There are better things to do instead.

So, can all OpenWatcom tools still be compiled 8086-compatible?

---
l
Back to index page
Thread view  Board view
22632 Postings in 2109 Threads, 402 registered users, 298 users online (0 registered, 298 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum