Hi, On Thu, Oct 10, 2019 at 11:08 AM TK Chia <u1049321...@caramail.com> 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
