Re: [Freedos-user] Tinyasm vs. NASM
Hi again, On Sat, Oct 12, 2019 at 8:15 AM TK Chia wrote: > > It seems that the precompiled nsm09839.zip binaries in iBiblio were > built with Microsoft C, most probably using Makefile.ms7. MS C 7 is from 1992, apparently. Maybe I'm naive, but I'll bet MSVC 1.52c from 1995 is a better compiler. > And the makefile has this...: > ># Compile for a 286, ain't nobody using an 8086 anymore >CC = cl /c /Oz /AL /Gt256 /G2 /I.. # MSC 7.00 > > I guess this explains why these particular binaries are 186+ only. Whoever built it also did this (presumably to fit into Large model) using DJGPP grep (and then DJGPP Perl to regenerate four source files): insns16.dat: insns.dat grep -v WILLAMETTE insns.dat | grep -v KATMAI | grep -v SSE | \ grep -v MMX | grep -v 3DNOW | grep -v UNDOC >insns16.dat But the problem is that this omitted some useful stuff ("UNDOC" includes SALC and LOADALL) but left in other random stuff (IA64's JMPE, Prescott non-SSE [MONITOR,MWAIT,FISTTP]). So, all these years, our default 16-bit build didn't even support all instructions *and* was 186 only! I'm actually probably going to refresh "nasmlite" again soon. It's basically cleaned up a bit with added P6 instructions (since it only added 2 kb for 35 instructions, who knows if someone finds that useful ... Jerome??). The improved makefile also easily supports a 586-only build. (I'll be honest, I don't know if CMOVcc is ever faster, so that makes it almost useless in my eyes. Less compatibility for zero gain? No thanks!) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi, On Thu, Oct 17, 2019 at 8:43 PM Rugxulo wrote: > > With the new [NASM 16-bit] build(s), I tried rebuilding the FD kernel. > It seems the TCPP101 version ran out of memory on KERNEL.ASM! It was actually only because I was using WmakeR (real mode) instead of the (386 pmode) Wmake executable. Not sure if WmakeR can swap out (apparently not, no mention in Tools documentation), haven't checked 2.0-pre. So that's the only reason. With Wmake [sic], it will happily assemble the kernel files with no problem. N.B. TC++ 1.01's Make 3.0 has -S (and .SWAP) and Dmake 4.00pl2 has % prefix for commands to swap out to disk, saving 50k or 100k RAM, respectively. WmakeR uses like 140 kb while (CWSTUB'd) Wmake only uses 40 kb. BTW, the only reason I was preferring WmakeR was to avoid any extender incompatibilities (CWSDPMI vs. DOS32A or WDOSX or whatever). But, AFAIK, Causeway (CWSTUB.EXE copied or renamed as DOS4GW.EXE) seems to play nicely (e.g. successfully runs NASM or UPX compiled by DJGPP). I already have scripts to (natively, in DOS) build various 32-bit NASMs via DJGPP (0.98.39 or 2.13.03) or OpenWatcom (2.09.10). So we don't need to forcibly rely on a 16-bit NASM binary just to rebuild the kernel. So it's not really a problem, just confusing. > Is that a tradeoff for using Huge model? Probably not, but you can't compile for Large model (anymore) without trimming out extraneous instructions ... so I decided to do that! (I call this "nasmlite".) I stripped out CYRIX/MMX/3DNOW and all SSE[123] stuff from insns.dat, re-ran "perl insns.pl", used "-d" (merge duplicate strings), and now that "lite" version compiles as (TC++ 1.01) Large model just fine. It saves about 50 kb .EXE space (or about 10 kb UPX'd). Trying to rebuild the kernel under WmakeR [sic] works fine (except for COUNTRY.SYS, which can be assembled manually later and isn't as high priority, obviously). * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Note that I made it so you don't need (abandoned, bloated) DJGPP Perl to rebuild this, only Sed, which is much smaller and has 16-bit builds. (I guess it's possible that 16-bit Perl 4 would work, but I highly doubt it and didn't try. Old NASM 0.97 had a .BAS to alternatively do it, but I guess it wasn't kept working, so I didn't try that here either.) I also didn't want to include three entire (regenerated) source files just for this when a simple script would avoid that dependency. > Should it use halloc() or overlays?? faralloc() ? Probably not. (You can rebuild with -DLOGALLOC to write statistics to malloc.log [big!], but that's not quite what I wanted to know.) Overlays? Still haven't read up on it (though I played a bit with Turbo Pascal overlays, for fun, kinda interesting.) Just FYI, for comparison. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Though I wonder why I wasted so much time since it's inferior to the 8086 OpenWatcom build. I guess I still appreciate Turbo C++ for what it is. I really need to take a look at why it's running out of memory Sorry for the late reply! Actually I will not be surprised, if the Open Watcom-compiled nasm was simply more efficient memory-wise. (At the very least, Open Watcom is known to use a more efficient function call interface by default, so there is that.) Another possibility is that the Turbo C++ version was triggering some memory corruption bugs which was causing spurious "out of memory" errors. Though I sure hope that was not the case. (kernel.asm) or maybe even look into using overlays (which I'm not familiar with at all). At least it does normally work, for comparison, in case anyone wants to improve it. (Me, I am not familiar with Turbo C++ overlays myself either --- perhaps someone else on this list is. I suspect that, to use overlays properly, one will have to know a bit more about the general control flow of the program, i.e. nasm, to guide the splitting of the program code.) Thank you! -- https://mastodon.social/@tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi Rugxulo, > Finally done, uploaded at the same place on iBiblio for us. > > * > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Congrats! :-) > Though I wonder why I wasted so much time since it's inferior to the > 8086 OpenWatcom build. I guess I still appreciate Turbo C++ for what > it is. I really need to take a look at why it's running out of memory > (kernel.asm) or maybe even look into using overlays (which I'm not > familiar with at all). At least it does normally work, for comparison, > in case anyone wants to improve it. Why do you think, you wasted your time? You did the TC++ build, because you were interested in. You probably learned a lot and your build is probably helpful for other in the future. Who knows! Be more optimistic. :-) Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi again, On Thu, Oct 17, 2019 at 8:43 PM Rugxulo wrote: > > Despite no actual code changes, I have improved my MAKEFILE.BOR again. > I may do some more fiddling (and also derive a TC201-compatible makefile). > It's also simple enough that I could just write a .BAT to build it. (I also > did > some local fixes to avoid dependency on sed. It's also reproducible now > (avoiding __DATE__), hence easy to verify. Finally done, uploaded at the same place on iBiblio for us. * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Though I wonder why I wasted so much time since it's inferior to the 8086 OpenWatcom build. I guess I still appreciate Turbo C++ for what it is. I really need to take a look at why it's running out of memory (kernel.asm) or maybe even look into using overlays (which I'm not familiar with at all). At least it does normally work, for comparison, in case anyone wants to improve it. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi, On Thu, Oct 10, 2019 at 11:08 AM TK Chia wrote: > > > But it's missing "[var+BX]" Effective Address support. > > Also, "MOV AX,..." (etc.) instructions use the bigger, non-optimal > > encodings. > > Well, perhaps there are ways to fix the support for these things in > tinyasm... = ; WACKY.ASM -- tested with Tinyasm (2019-Oct-08) mov ax,word[alpha]; 8B 06 1201 mov ax,[0x112] mov ax,[alpha];A1 1201 " " mov al,byte[beta] ; 8A 06 1301 mov al,[0x113] mov al,[beta] ;A0 1301 " " mov bx,[bx+zeta] ; 8B 9F 1401 mov bx,[bx+0x114] ; mov bx,[zeta+bx] ; *** won't even assemble! *** alpha: db 'a' beta: db 'b' zeta: db 'z' ; EOF = So it's a bit picky with what syntax it accepts, but it does (already!) support it correctly. Just FYI. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)
On at 2019-10-26 03:09 -0500, Rugxulo wrote: >> I also worked some on an 8086tiny fork of mine recently. There are >> several bugfixes there, as well as implementing all 186 instructions, so >> it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/ > > I tested all of this under Linux (Xenial Puppy, 64-bit) jump drive. > > It seems you're missing "lmacros3.mac" (not found) for tinyxms, but I > just ignored that for now: "make no_graphics -k -i" or whatever. (I > just used a modified version of my old BARE_DOS floppy image.) Oh yes, that was not intended. I think the included fd.img does have the compiled tinyxms.sys already, but to build it from source you need to load all of lmacros[123].mac from https://hg.ulukai.org/ecm/lmacros and put them in one of the directories included by the NASM run: > tinyxms.sys: tinyxms.asm > nasm -f bin -I ../lmacros/ -I lmacros/ -l tinyxms.lst -o tinyxms.sys tinyxms.asm That is, either copy the three macro files to the same directory as tinyxms.asm, or to an lmacros subdirectory, or to an lmacros sibling-directory of the 8086tiny directory. Regards, ecm ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)
Hi, (sorry for delay in testing) On Tue, Oct 8, 2019 at 10:17 AM C. Masloch wrote: > > On at 2019-10-05 18:49 -0500, Rugxulo wrote: > > "Unfortunately, nasm doesn't run over 8086/8088 processors,and I > > couldn't find a compatible assembler!" > > > > Strange. I was lightly playing with 8086tinyplus (on Windows) > > recently, and I noticed that the (in)famous 16-bit NASM build from > > 2005 of 0.98.39 didn't seem to run properly. (But that could be an > > emulator bug. It runs fine under QEMU. I know 8086tinyplus can't > > handle 186+ ENTER/LEAVE properly.) > > If the 16-bit NASM uses 186+ instructions, that's a bug (or possibly > wrong option?) on the part of the compiler. The default 2005, 16-bit NASM build seems to work correctly under your (improved) fork of 8086tiny. So indeed, it must've been compiled for 186. > I also worked some on an 8086tiny fork of mine recently. There are > several bugfixes there, as well as implementing all 186 instructions, so > it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/ I tested all of this under Linux (Xenial Puppy, 64-bit) jump drive. It seems you're missing "lmacros3.mac" (not found) for tinyxms, but I just ignored that for now: "make no_graphics -k -i" or whatever. (I just used a modified version of my old BARE_DOS floppy image.) Yeah, it seems to work better (than 8086tinyplus). I did keep around a 186, Oberon-M build of my Befunge-93 interpreter (bef186om.exe) just for identifying these kinds of bugs (mostly thinking of Fake86 here). Even that .EXE works here. So that's cool. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi again, Just to follow up On Thu, Oct 10, 2019 at 11:08 AM TK Chia wrote: > > > But it's missing "[var+BX]" Effective Address support. > > Well, perhaps there are ways to fix the support for these things in tinyasm... As mentioned, since I've written a .BAT / sed combo to work with Tinyasm for PSR Invaders, I finally uploaded both to iBiblio for us. (BSD 2-clause is still Free, so that's good.) TODO: benchmark again under 8086tinyplus. * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/tinyasm/ * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/psrinvad.html Of course, after having uploaded it, then (Murphy's Law) I accidentally found out that Tinyasm *does* support [BX+var] syntax (note that "BX+" must come first). So I had wasted a bunch of scripting lines trying to work around that, unnecessarily, ugh. I obviously didn't check the included examples (rogue.asm). Still, strange that it's only supported in that way, but whatever. Oh, BTW > I can sort of understand why Mr. Oscar did not try to include upx in the > build pipeline: it is (I think) not very possible yet to build upx > itself on a small, 16-bit machine. If he insists on building everything from scratch, okay. Otherwise, I recommend "classic" DIET 1.45f "freeware": * https://www.sac.sk/download/pack/diet145f.zip The TCPP101 build of NASM, for example, compresses down to 100 kb with "diet -X" (versus 81 kb with UPX, not counting another 10 kb savings if you enable slow --lzma). Oh, I did locally recompile with -1 (186), but it only saved 3 kb (and none after UPX), so that's effectively useless. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi again, On Sat, Oct 12, 2019 at 8:15 AM TK Chia wrote: > > > Okay, I think I've done enough fiddling to be worth sharing. > > > > Further testing and contributions are welcome, of course. > > Thanks! This looks like ... a rather major revamp of the makefiles. :-) With the new build(s), I tried rebuilding the FD kernel ("tests /t ke2041" under MetaDOS, "set NASMENV=-O9v" first). It seems the TCPP101 version (NAS16TCC) ran out of memory on KERNEL.ASM! (Dunno why, haven't checked closely yet.) Is that a tradeoff for using Huge model? Or some other problem? Naive question: should it use halloc() or overlays?? Ugh. (I need to study the manuals closer, too.) But the OpenWatcom (Large model) build (NAS16WAT) seemed to work fine (KERNEL.SYS' CRC32 matches). FreeDOS wisely prefers OW anyways, but still Despite no actual code changes, I have improved my MAKEFILE.BOR again. I haven't uploaded it yet. I may do some more fiddling (and also derive a TC201-compatible makefile). It's also simple enough that I could just write a .BAT to build it. (I also did some local fixes to avoid dependency on sed. That was the whole reason for my included SNPRINTF.DIF, to not burden anyone with that requirement.) It's also reproducible now (avoiding __DATE__), hence easy to verify. Just FYI. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi, (BTW, thanks for the binary, I'll test it out.) On Sat, Oct 12, 2019 at 6:03 PM Rugxulo wrote: > > >>> I still want to get PSR Invaders working with it > > I've done it! :-) (No, I haven't updated the FD Package yet.) If you're super bored, check it out: * https://pastebin.com/vj0FTvqy * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/games/invaders/invadr11.zip ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, Using the above command line, the resulting size of tinyasm.exe is 27,200 bytes. With the DJGPP-hosted tools, I'm getting 45 kb. Is that correct? Or do you have newer libs? Sure, after UPX, it's about 27 kb. Either way, quite nice! Ah yes, I have updated the gcc-ia16 toolchain on my end to fix a problem with the -mnewlib-nano-stdio switch --- I hope to make a new release of the toolchain some time soon. The compiled tinyasm.exe is 27,200 bytes without applying upx compression. Thank you! -- https://github.com/tkchia tinyasm.exe.bin Description: Binary data ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi, On Sat, Oct 12, 2019 at 8:15 AM TK Chia wrote: > > Thanks! This looks like ... a rather major revamp of the makefiles. :-) For TC++, I tried to minimize loading the compiler too many times. It's able to compile multiple sources together in one invocation, which I guess is possibly faster (dunno ... for something like DJGPP it's not, AFAIK). Part of the problem is simple CFLAGS switches (which waste precious cmdline space, but using a response file is too messy here), so I (half) disabled USINGXMS just so it wouldn't unnecessarily reload the compiler. (I have no idea if that helps either. It's not default, but EMS will be used if found.) Then I did a dopey kludge just to make sure it would compile outbin.c and outobj.c both at once and not erroneously try to do it again. (Some makes let you do this easily, others not. It can get complicated fast.) > It seems that the precompiled nsm09839.zip binaries in iBiblio were > built with Microsoft C, most probably using Makefile.ms7. And the > makefile has this...: > ># Compile for a 286, ain't nobody using an 8086 anymore Maybe it was for smaller size, and thus saved RAM? Otherwise it makes little sense. Sure, 8086 clones aren't as popular, but just from an emulator standpoint (and the fact that it's possible at all), there should've been separate builds. (Besides, like I said, 186+ ENTER is tons slower on semi-modern machines!) >> Using the above command line, the resulting size of tinyasm.exe is 27,200 >> bytes. With the DJGPP-hosted tools, I'm getting 45 kb. Is that correct? Or do you have newer libs? Sure, after UPX, it's about 27 kb. Either way, quite nice! >>> I still want to get PSR Invaders working with it, I haven't quite done it >>> yet. >>> (I may or may not be able to mentally wrangle around the quirks with Sed >>> scripting. I'm only half successful so far. I've done it! :-) Sure, it took some workarounds for those issues I mentioned before, but I'd already done similarly for Octasm. (Even with functionally-identical instructions, if the size is different, it makes verifying everything much more tedious.) So yeah, now it's 100% identical to NASM output (all with simple sed scripts, the whole .BAT is less than 3 kb). I doubt anyone cares besides me, but I like it! (No, I haven't updated the FD Package yet.) Now, one of these days, I need to test a bunch more of this stuff under 8086tinyplus (again). ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, I for one would like to know how you wrote the makefiles for nasm --- I have not managed to get a 16-bit build working using Watcom. Okay, I think I've done enough fiddling to be worth sharing. So here it is (lacking any better place for us): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Further testing and contributions are welcome, of course. Thanks! This looks like ... a rather major revamp of the makefiles. :-) It seems that the precompiled nsm09839.zip binaries in iBiblio were built with Microsoft C, most probably using Makefile.ms7. And the makefile has this...: # Compile for a 286, ain't nobody using an 8086 anymore CC = cl /c /Oz /AL /Gt256 /G2 /I.. # MSC 7.00 I guess this explains why these particular binaries are 186+ only. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello! On Thu, Oct 10, 2019 at 11:08 AM TK Chia wrote: > > > doing that tomorrow. The makefiles are messy, and I'm no make expert, > > but they should both be 100% reproducible (if anyone is honestly > > interested). If I don't find any obvious problems, I'll probably > > I for one would like to know how you wrote the makefiles for nasm --- I > have not managed to get a 16-bit build working using Watcom. Okay, I think I've done enough fiddling to be worth sharing. So here it is (lacking any better place for us): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Further testing and contributions are welcome, of course. IIRC, you can type "whelp tools" to read about OpenWatcom's Wmake. With that advice, I greatly simplified the included makefile.wcd , and it seems to work. (However, I have not tested again under 8086tinyplus yet, but I assume I didn't break anything.) I also greatly improved the makefile.bor for freeware TC++ 1.01. Compared to older (TC 2.01 or TP 5.5) make, it's much improved. I read through Chapter 12 of the User's Guide (dead tree edition), which helped a lot. In the past, I've also used FreeDOS' Dmake build, which works fairly well. But that had some problems under Fake86 (emulator, miscompiled??), so I ended up just writing a "simple" .BAT instead (for one project of mine). You know, you don't have to only use the included Make with a certain compiler. You can use any others. I kinda doubt TC 2.01's Make is worth using, but I'm still (barely) sympathetic. Ironically, despite claiming MCGA support, 8086tinyplus doesn't play PSR Invaders at all, gets stuck somewhere. Go figure. (I think the BIOS for 8086tiny was written with NASM, but I've never looked closely nor recompiled it.) I need to test under 8086tinyplus again, for various reasons. In particular, measure some timings on reassembling PSR Invaders. I can think of a few tricks to try to speed it up (on my end, in scripting, without rebuilding NASM again). I'm not super familiar with truly classic/retro machines. I can only imagine. Well, some people (ahem, LGR) know what they're doing (not me). :-) * https://monotech.fwscart.com/NuXT_MicroATX_Turbo_XT_955MHz_832K_RAM_XTCF_SVGA_Floppy_Serial/p6083514_19777986.aspx For those machines, I'd assume a RAM disk would help a lot. And using suitable tools (A86/D86, AWK, Turbo Pascal, some kind of Forth, maybe QBASIC), of course. But I disagree that you can "only" cross-compile for such "embedded" machines. Sure, that's valid too (FPC's i8086-msdos), and I'm not complaining about that. But there's still "some" things you can do natively! I swear, optimizing for old machines (with their limits) helps software for new machines run better and faster, too! Limits are actually good sometimes. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
On Fri, Oct 11, 2019 at 4:57 AM TK Chia wrote: > Hello dmccunney, > > > Er, how much do we actually *care* about EXE size on disk? Even folks > > going old skool and trying to run on 808X CPUs are likely to have > > decent HDs.. (Is *anyone* still trying to run DOS (MS/PC or FreeDOS) > > and DOS apps entirely off of 360K floppies?) In that case, UPX may > > Well, I guess we are simply obsessed with code size. :-) I think > generally it is OK to try making programs as small as possible, as long > as it does not add too much inconvenience. Yeah, obsessed is a good word for it. :-) I'm all in favor of small code size, but you have a trade off. The fastest code is entirely inline. But going that route means larger executables, as code normally contained in libraries and called via functions is instead directly in the code where ever those library functions are used. And many efforts to optimize for size create problems. In general, on larger systems, the compiler can do a better job of optimization than the programmer can, and the trick is setting the right compiler options when you do a build. Some of the games programmers play to optimize directly in their code can fool an optimizing compiler and result in *larger* code. I personally don't care whether UPX is in the mix building this. I can understand the problems of including UPX in a build. I think a fair bit of what we already use has to be built on a larger machine and cross-compiled for a 16 bit target. I'm pretty sure everyone who might *want* to build from source *has* a larger machine where it will be done, and just wants to *run* the code on the low end machine. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ tinyasm.c ins.c -o tinyasm.exe What is the resulting size of the .EXE with your build? (He said it uses at least 128k RAM, right?) At least for development and Using the above command line, the resulting size of tinyasm.exe is 27,200 bytes. I can sort of understand why Mr. Oscar did not try to include upx in the build pipeline: it is (I think) not very possible yet to build upx itself on a small, 16-bit machine. Hello dmccunney, Er, how much do we actually *care* about EXE size on disk? Even folks going old skool and trying to run on 808X CPUs are likely to have decent HDs.. (Is *anyone* still trying to run DOS (MS/PC or FreeDOS) and DOS apps entirely off of 360K floppies?) In that case, UPX may Well, I guess we are simply obsessed with code size. :-) I think generally it is OK to try making programs as small as possible, as long as it does not add too much inconvenience. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
On Thu, Oct 10, 2019 at 10:00 PM Rugxulo wrote: > >ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ > > tinyasm.c ins.c -o tinyasm.exe > > What is the resulting size of the .EXE with your build? (He said it > uses at least 128k RAM, right?) At least for development and > debugging, he should use a more comfortable toolset. Bootstrapping > (using 8086 host-friendly tools) can be important, too, but (Hey, > he didn't even UPX the 30 kb .EXE! Maybe that was intentional??) Er, how much do we actually *care* about EXE size on disk? Even folks going old skool and trying to run on 808X CPUs are likely to have decent HDs.. (Is *anyone* still trying to run DOS (MS/PC or FreeDOS) and DOS apps entirely off of 360K floppies?) In that case, UPX may provide an advantage because it will be faster to decompress the EXE into memory once it's loaded from disk than to load the uncompressed one from disk. If you have a decent HD, the space taken on disk is far less of a concern, and there is unlikely to be a load speed advantage loading a compressed executable from disk.) If you can think of reasons why UPX provides an advantage, I'll sit corrected, but the more likely concern is the amount of RAM required, and any magic that must be done to load as much as possible high. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi, On Thu, Oct 10, 2019 at 11:08 AM TK Chia wrote: > > > BTW, what is the proper way to build Tinyasm with IA16-GCC? Is there a > > specific set of switches you use? > > To really crunch down the size, you can add some options to turn on > optimizations and use a more efficient function call interface: > >ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ > tinyasm.c ins.c -o tinyasm.exe What is the resulting size of the .EXE with your build? (He said it uses at least 128k RAM, right?) At least for development and debugging, he should use a more comfortable toolset. Bootstrapping (using 8086 host-friendly tools) can be important, too, but (Hey, he didn't even UPX the 30 kb .EXE! Maybe that was intentional??) > No, I have not really tested the ia16-elf-gcc version very much. But I > think ia16-elf-gcc + newlib-ia16 is actually a bit easier to work with > than DeSmet C (the DeSmet runtime's C89 support is still rather > incomplete and buggy, at least for now). I've not used DeSmet much. It seems pretty good for what it does. I'm still sympathetic, but I've preferred other things lately (Turbo Pascal, FPC, etc). > > doing that tomorrow. The makefiles are messy, and I'm no make expert, > > but they should both be 100% reproducible (if anyone is honestly > > interested). If I don't find any obvious problems, I'll probably > > I for one would like to know how you wrote the makefiles for nasm --- I > have not managed to get a 16-bit build working using Watcom. I just modified the included mkfiles/makefile.bor and mkfiles/makefile.wcd to build atop FreeDOS natively on my laptop. Testing under 8086tinyplus (1.34, win32/winapi) shows that both versions (Turbo C++, OpenWatcom) seem to work fine, at least for reassembling PSR Invaders. So that's good! I did UPX them (--ultra-brute --8086 ... not using slow --lzma !!), so that may still partially affect the speed a bit. I had other utils UPX'd too, so my measurements may be off. (Small capacity, slow floppies, what do you do? Conventional RAM disk? TDSK??) I also set it to use fastest speed instead (20 Mhz) of default 4.77 Mhz. Roughly, the sed script took 15 secs. while the assembly itself was less than two minutes. (And the CRC32 of the outputted .COM matched, so it did actually succeed.) The two versions seem comparable in speed although I did use Huge for Turbo and (default) Large for OpenWatcom. So it's TC = 256k .EXE (81k) and OW = 238k (94k). Hmmm, at original speed (4.77 Mhz), it seems to have taken 1 minute (sed) and a little over 7 minutes (nasm). That may be because of other reasons (Windows, multitasking or whatever). I'm not even sure if it was meant to be exact in instruction timing. Not ideal for 8086 native development speed, obviously, but some of that is because of -O9. (If you hardcode "byte" and "short", you don't need that. It's only for programmer convenience.) I'm sure many other tricks can be done to speed up development on such classic/retro machines. It's like a lost art, honestly. Oh! "mem /c" says "464k (475,000) bytes free", so I didn't even need "call /s" (which would roughly free up 100k)! It still feels imperfect (my makefile kludges), but I may just go ahead and upload what I have soon enough (since it works). It doesn't have to be perfect, but I still feel incomplete. Feel free to advise me. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, BTW, what is the proper way to build Tinyasm with IA16-GCC? Is there a specific set of switches you use? Or have you not tested (much) with it yet? The bare minimum is to enable the "small" memory model (separate text and data segments), like so: ia16-elf-gcc -mcmodel=small tinyasm.c ins.c -o tinyasm.exe or i16gcc -mcmodel=small tinyasm.c ins.c -o tinyasm.exe To really crunch down the size, you can add some options to turn on optimizations and use a more efficient function call interface: ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ tinyasm.c ins.c -o tinyasm.exe (I have updated my build-ia16 scripts at https://github.com/tkchia/build-ia16 to build tinyasm using ia16-elf-gcc with my above "recommended" options.) No, I have not really tested the ia16-elf-gcc version very much. But I think ia16-elf-gcc + newlib-ia16 is actually a bit easier to work with than DeSmet C (the DeSmet runtime's C89 support is still rather incomplete and buggy, at least for now). of terminology. But it's missing "[var+BX]" Effective Address support. Also, "MOV AX,..." (etc.) instructions use the bigger, non-optimal encodings. I haven't quite identified some other quirks yet (beyond simple stuff like hex number syntax [0Ah not supported], quirky "mylabel: dw 5", seg overrides only at beginning of line, etc). Well, perhaps there are ways to fix the support for these things in tinyasm... doing that tomorrow. The makefiles are messy, and I'm no make expert, but they should both be 100% reproducible (if anyone is honestly interested). If I don't find any obvious problems, I'll probably I for one would like to know how you wrote the makefiles for nasm --- I have not managed to get a 16-bit build working using Watcom. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hi, On Tue, Oct 8, 2019 at 11:48 AM TK Chia wrote: > > I did a quick disassembly of the precompiled nasm.exe and ndisasm.exe in > nsm09839.zip, and indeed --- for some reason --- they were built to use > 186+ instructions such as `leave' and immediate pushes. > > So perhaps it will be good to try to rebuild this version of nasm, for > the 8086. (TINYASM) First, let me mention a few things I've noticed about Tinyasm: BTW, what is the proper way to build Tinyasm with IA16-GCC? Is there a specific set of switches you use? Or have you not tested (much) with it yet? Tinyasm seems to work okay (although line number / error reporting is a bit backwards). It still lacks a few things, but I know it's still very early in development. I'm no expert, so please forgive my misuse of terminology. But it's missing "[var+BX]" Effective Address support. Also, "MOV AX,..." (etc.) instructions use the bigger, non-optimal encodings. I haven't quite identified some other quirks yet (beyond simple stuff like hex number syntax [0Ah not supported], quirky "mylabel: dw 5", seg overrides only at beginning of line, etc). I'm not opposed to uploading Tinyasm to iBiblio, but since I still want to get PSR Invaders working with it, I haven't quite done it yet. (I may or may not be able to mentally wrangle around the quirks with Sed scripting. I'm only half successful so far. Yes, I know Oscar has his own smaller invaders clone, but the difficulty is much harder. I still regret that the old one is VGA-only, but apparently he doesn't!) I've done still more tweaking (indirectly) to PSR Invaders in recent months, so I'll probably update the FD Package "yet again" for us soon. (NASM) Now, let me mention NASM (old 0.98.39 from 2005, from which we have a pre-existing [broken?] 16-bit build): I did rebuild it with both Turbo C++ 1.01 and OpenWatcom 1.9. I found that TC++ (mkfiles\makefile.bor) was harder to get working (and it didn't fit into Large model, so I switched to Huge). For both, I only included outputs "bin" and "obj", which I think is reasonable. They do work, but I haven't tested under 8086tinyplus (again) yet. I'll try doing that tomorrow. The makefiles are messy, and I'm no make expert, but they should both be 100% reproducible (if anyone is honestly interested). If I don't find any obvious problems, I'll probably upload my weak efforts to iBiblio for us. Hopefully someone else can then further verify and improve upon my attempt. Obligatory link: https://www.stevemorse.org/8086/index.html ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)
Hi, On Tue, Oct 8, 2019 at 10:17 AM C. Masloch wrote: > > On at 2019-10-05 18:49 -0500, Rugxulo wrote: > > I know 8086tinyplus can't handle 186+ ENTER/LEAVE properly. > > If the 16-bit NASM uses 186+ instructions, that's a bug (or possibly > wrong option?) on the part of the compiler. They seem to have used different 16-bit compilers over the years (the internal C runtime copyright is different). Perhaps it was the only way to fit it into Large model, dunno. But I also think it was a mistake to include output support beyond "bin" and "obj" (e.g. "as86" and "win32", who is cross-assembling atop 8086 for those??). Then again, few people complained nor rebuilt it themselves. Granted, their included makefiles are less than optimal (either buggy, poorly written [no offense!], or rely on very specific versions). I'm no makefile guru (and make utils are all wildly incompatible), but it takes some serious effort. > I also worked some on an 8086tiny fork of mine recently. There are > several bugfixes there, as well as implementing all 186 instructions, so > it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/ Well, I just meant, from previous experience, that Fake86 and 8086tiny (and 8086tinyplus) both didn't handle ENTER properly. (LEAVE is simplistic and probably fine.) Oberon-M 1.2 added optional 8086 support, but the more-widespread 1.1 version (Simtel? Garbo?) was 186 only (and did actually use ENTER/LEAVE). Ironically, ENTER/LEAVE are several times slower on my modern-ish laptop and desktop (dunno why, microcoded??). Most compilers (e.g. GCC or FPC) avoid them entirely for various reasons. I would be surprised if that was the "only" reason. Like I said, NASM 0.97 worked fine in 8086tinyplus (but is less optimal, doesn't optimize for size and only goes up through MMX). So it's something introduced after that point. Note that I'm not talking about slow or even very slow, only actually broken and non-functional binaries. Old hardware is definitely slow, and there is definitely a point where software is too slow to be useful. But here I think we just have an incompatible build. (I did rebuild it myself, but it needs further testing, even from me. I'll write a different email about that.) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)
On at 2019-10-05 18:49 -0500, Rugxulo wrote: > "Unfortunately, nasm doesn't run over 8086/8088 processors,and I > couldn't find a compatible assembler!" > > Strange. I was lightly playing with 8086tinyplus (on Windows) > recently, and I noticed that the (in)famous 16-bit NASM build from > 2005 of 0.98.39 didn't seem to run properly. (But that could be an > emulator bug. It runs fine under QEMU. I know 8086tinyplus can't > handle 186+ ENTER/LEAVE properly.) If the 16-bit NASM uses 186+ instructions, that's a bug (or possibly wrong option?) on the part of the compiler. I also worked some on an 8086tiny fork of mine recently. There are several bugfixes there, as well as implementing all 186 instructions, so it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/ > Even other NASM versions had > issues. (A86 and Wolfware/WASM worked fine, though.) Actually, I think > I ran my old BARE_DOS floppy and used "call /s", and then at least > NASM 0.97 worked. I meant to try to recompile NASM 0.98.39 with both > Turbo C and OpenWatcom (supporting bin only or bin+obj only) and test, > but I never found the extra time and energy. > > * https://jaybertsoftware.weebly.com/8086-tiny-plus.html > * > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/ > > Comments on further testing welcome! Regards, ecm ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)
Hi, On Fri, Oct 4, 2019 at 3:13 AM Random Liegh via Freedos-user wrote: > > I just spotted this on reddit and thought someone here might appreciate it: > > https://github.com/nanochess/tinyasm/ > > Brand spanking new, targets the 8088. It can be built with desmet-c, but > there's a precompiled binary included in the github repository. 30 kb .EXE? Interesting. Ah, Oscar Toledo! A true genius. "Save a hard drive today!" (Memorable quote that always makes me laugh.) I hope his family is well and healthy. "Unfortunately, nasm doesn't run over 8086/8088 processors,and I couldn't find a compatible assembler!" Strange. I was lightly playing with 8086tinyplus (on Windows) recently, and I noticed that the (in)famous 16-bit NASM build from 2005 of 0.98.39 didn't seem to run properly. (But that could be an emulator bug. It runs fine under QEMU. I know 8086tinyplus can't handle 186+ ENTER/LEAVE properly.) Even other NASM versions had issues. (A86 and Wolfware/WASM worked fine, though.) Actually, I think I ran my old BARE_DOS floppy and used "call /s", and then at least NASM 0.97 worked. I meant to try to recompile NASM 0.98.39 with both Turbo C and OpenWatcom (supporting bin only or bin+obj only) and test, but I never found the extra time and energy. * https://jaybertsoftware.weebly.com/8086-tiny-plus.html * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/ Comments on further testing welcome! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user