Hi, On Tue, Oct 8, 2019 at 10:17 AM C. Masloch <pus...@ulukai.org> 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
