ACK i86/i386 output & DOS (Developers)
> Over the recent years, there's been some work on a new version 6.0 (it is
> licensed under the 3-clause BSD license), which as of yet allows creation
> of (Real 86 Mode, naturally) 8086 code or (only(?) 32-bit Protected Mode, I
> assume) 386 code out of the box, as far as I understand it. However, the
> former's only targeted platform is "pc86 (bootable floppy disk images)"
> (probably uses BIOS services?) and the latter's only one is "linux386 (ELF
> Linux executables)". The names of those formats are specified here:
> http://tack.sourceforge.net/about.html
Right, I think one guy (only?), David Given, had hacked on it for a few years to produce a slimmed 6.0 version that supported only like two or three targets and actually builds on modern *nix machines without weird kludges (though he now in 6.x uses a Lua builder, wha??). N.B. to Arjay, it also supports CP/M 8080, apparently.
But I think he barely has time for it anymore, and he kinda gave up (esp. his PPC port) as register-based is too clunky and bad for modern machines. So I dunno how much work is going in to it anymore (though he did, vaguely, update it once or twice in recent years. But the mailing list is a ghost town.)
I've vaguely used it atop PuppyLinux (and also in DOS-Minix), and it's a nice compiler with a few interesting frontends. I actually appreciate the pc and m2 compilers, but I suspect you only are interested in cc (and its libs). Well, we are mostly talking about 16-bit C for x86 FreeDOS here, so that's valid. But still, pc and m2 are good too. (There are other frontends supported too but much less tested and useful overall.)
> It probably wouldn't require great amounts of effort to add a simple
> "dos86" platform sharing the i86 code generator; at first, this would
> minimally only have to create programs that are loadable as DOS
> executables*, which consider what resources (memory etc) they are provided
> by DOS, and which terminate the DOS process when they exit.
The easiest thing would be to resurrect the em44 interpreter via DJGPP or such, but I've not tried. The next easiest would be to add a few stub functions to the library and allow cross-compiling for DOS. Of course, part of the problem is translating its quirky a.out variant to native DOS format(s). Or maybe BCC/Dev86's linker would (also) support it already? Dunno. (Minix used to use BCC.)
> It should also
> (allow) switch(ing) to DOS's I/O functions instead of the BIOS's (which as
> I noted I think it currently uses; it is a while ago that I skimmed the
> source), though that is not strictly necessary of course.
pc86 seems useless to me almost. If you can't even do file access, what can you do? Just bare computation? I know people complain that DOS is a glorified boot loader, but at least it (and BIOS) ease things tremendously over having to do it all from scratch. Besides, it's not like DOS is totally undocumented or obscure or anything (API -> RBIL), so it shouldn't (in theory) be hard to port (famous last words!!).
> * Of course this could potentially be programmed to create .COM (flat)
> executables if the output is small enough
I think its 16-bit output is separate I&D, i.e. tiny or small model only. In 16-bit Minix it actually shared code pages between background instances in order to save RAM. So I'm not sure how hugely useful the 16-bit compiler is unless you can live with that limitation. (Though 386 code has no such problems, assumedly.)
> , but .EXE (MZ header) executables
> are the more general case and additionally (seen strictly) require less
> run-time stack space validation if the header fields are correctly used to
> make DOS take care of insuring that enough stack space is available.
Yes, .EXE is probably more comfortable, though I don't think the binaries will be very big as it seems pretty efficient and the runtimes are pretty small too (smallest to largest output seem to be pc, cc, m2; see here for a few notes about ACK overall, mostly m2 related).
Complete thread:
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 17.04.2012, 02:18 (Developers)
- Dev86DOS 0.16.18 (DJGPP host) - georgpotthast, 17.04.2012, 18:23
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 17.04.2012, 19:42
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 18.04.2012, 01:54
- Dev86DOS 0.16.18 (DJGPP host) - georgpotthast, 19.04.2012, 18:41
- Dev86DOS 0.16.18 (DJGPP host) - roytam, 21.04.2012, 13:52
- Dev86DOS 0.16.18 (DJGPP host) - georgpotthast, 21.04.2012, 16:25
- Dev86DOS 0.16.18 (DJGPP host) - Khusraw, 22.04.2012, 09:34
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 22.04.2012, 18:08
- ACK i86/i386 output & DOS - ecm, 22.04.2012, 23:24
- ACK i86/i386 output & DOS - Rugxulo, 26.04.2012, 09:33
- ACK i86/i386 output & DOS - tkchia, 01.04.2021, 16:50
- ACK i86/i386 output & DOS - ecm, 01.04.2021, 17:11
- ACK i86/i386 output & DOS - ecm, 22.04.2012, 23:24
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 22.04.2012, 18:08
- Dev86DOS 0.16.18 (DJGPP host) - Khusraw, 22.04.2012, 09:34
- Dev86DOS 0.16.18 (DJGPP host) - georgpotthast, 21.04.2012, 16:25
- Dev86DOS 0.16.18 (DJGPP host) - roytam, 21.04.2012, 13:52
- Dev86DOS 0.16.18 (DJGPP host) - georgpotthast, 19.04.2012, 18:41
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 18.04.2012, 01:54
- Dev86DOS 0.16.18 (DJGPP host) - Rugxulo, 17.04.2012, 19:42
- Dev86 0.16.19 (DJGPP host) - Khusraw, 17.09.2012, 14:47
- Dev86 0.16.19 (DJGPP host) - Rugxulo, 19.09.2012, 02:07
- Dev86 0.16.19 (DJGPP host) - Khusraw, 19.09.2012, 09:05
- Dev86 0.16.19 (DJGPP host) - Rugxulo, 19.09.2012, 02:07
- Dev86DOS 0.16.18 (DJGPP host) - georgpotthast, 17.04.2012, 18:23