Re: [Freedos-user] Tinyasm vs. NASM

2020-04-12 Thread Rugxulo
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

2020-03-21 Thread Rugxulo
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

2019-12-02 Thread TK Chia

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

2019-12-01 Thread Robert Riebisch
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

2019-11-30 Thread Rugxulo
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

2019-10-26 Thread Rugxulo
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)

2019-10-26 Thread C. Masloch
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)

2019-10-26 Thread Rugxulo
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

2019-10-20 Thread Rugxulo
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

2019-10-17 Thread Rugxulo
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

2019-10-13 Thread Rugxulo
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

2019-10-12 Thread TK Chia

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

2019-10-12 Thread Rugxulo
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

2019-10-12 Thread TK Chia

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

2019-10-12 Thread Rugxulo
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

2019-10-11 Thread dmccunney
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

2019-10-11 Thread TK Chia

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

2019-10-10 Thread dmccunney
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

2019-10-10 Thread Rugxulo
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

2019-10-10 Thread TK Chia

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

2019-10-10 Thread Rugxulo
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)

2019-10-10 Thread Rugxulo
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)

2019-10-08 Thread C. Masloch
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)

2019-10-05 Thread Rugxulo
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