DOS ain't dead

Hi DosWorld (and anyone else interested)

> Sorry, i am not check Robert's work. I'll check as86.

> (Right now, i'm sure he produce MZ in tiny or small memory model.
> But need check - may be Robert invent something and escape from this
> restriction?)

Today I finally managed to prove that as86 works on a large memory model program. Even though it uses a.out for the object code format. I made the PDOS bootloader large memory model, in preparation for converting it to huge. Here is the makefile I used:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/makeio.std

I was wondering if I was going to hit some roadblock that I hadn't thought of, but nothing so far, to large. It's unlikely that there will be a roadblock found when switching to huge.

There are a couple of anomalies - I haven't attempted to do the stack pointer properly yet, nor clear BSS. And I had to hardcode the opcode for retn. I'll look at cleaning up those things soon, and hopefully don't find a roadblock then.

It took a huge effort just to get to this point, because I needed to isolate faults in both as86 and ld86.

Robert's goal for as86 is to accept masm syntax, but not necessarily produce byte-identical object code, so I can't easily compare binaries to see anything wrong.

Good news is that even coped with mixing RM16 and PM32 code.

Pretty impressive for something as simple as a.out.

Oh - one other restriction. You can't use the "seg" keyword, because a.out can't carry that across. But you don't actually need to use that keyword. There is a way to work around that - just declare a variable with "dd" that references the function you want to get the segment of.

And if the C compiler is generating the "seg" keyword, then declare a function pointer.

My plan is to get either SubC or Octogram C (both public domain, but both not reaching C90) to generate huge memory model code, and not use the "seg" keyword, so no mucking around required.

BFN. Paul.

> I was wondering if I was going to hit some roadblock that I hadn't thought
> of, but nothing so far, to large. It's unlikely that there will be a
> roadblock found when switching to huge.

No roadblock, but more bugs uncovered and fixed.
And now huge is working.

> There are a couple of anomalies - I haven't attempted to do the stack
> pointer properly yet, nor clear BSS. And I had to hardcode the opcode for
> retn. I'll look at cleaning up those things soon, and hopefully don't find
> a roadblock then.

These have all been cleaned up and all work now.

a.out is perfectly fine for MSDOS programming,
with the caveat that you must use complete
addresses, or offsets, and not attempt to
extract just the segment. There's not a lot of
code that tries to use "seg", and it is not
necessary to use it in anything I have seen.

BFN. Paul.

You should look into gcc-ia16; the related binutils-ia16 has an as binary capable of producing 8086 code and a ld capable of linking together both tiny-model (.COM) and small-model (.EXE) executables. The gcc-ia16 port from tkchia has some weak support for medium model, with no apparent changes in the linker code for it, so perhaps assembly language programs can already use medium, large, and huge with it.

> You should look into gcc-ia16; the related binutils-ia16 has an
> as binary capable of producing 8086 code and a ld
> capable of linking together both tiny-model (.COM) and small-model (.EXE)
> executables. The gcc-ia16 port from tkchia has some weak support for medium
> model, with no apparent changes in the linker code for it, so perhaps
> assembly language programs can already use medium, large, and huge with it.

I think his real motivation is moreso "only public domain" and PDOS/PDPCLIB. But I think he uses GCC 3.2 somewhere (MVS?). (To be honest, I don't know all of the details.) I'm just saying, suggesting that he lean more heavily on GCC 6.3.0 and its associated GPLv3 ELF tools is probably not going to happen. (At least, that's what T.K. Chia's i16gcc packages use, IIRC.) I suggested SmallerC [BSD] once, but he didn't seem too interested. That (also) uses ELF. IIRC, it's a GNU extension to the ELF format to allow 16-bit relocations. (SmallerC still uses an external assembler, e.g. NASM, but 16-bit huge model .EXEs are not supported by FASM / n2f due to this, only 32-bit pmode .EXEs.) He seemed uninterested in NASM [BSD] either.

a.out predates COFF. In fact, DJGPP used to use a.out before switching to COFF. OS/2's EMX (mostly?) used a.out also, IIRC.

You can already use any GAS and LD (with linker script) to output a 16-bit .COM file, not just the ones from IA-16 ELF GCC. Martin Stromberg provided a linker script to DJGPP years ago to do so, probably based upon his XMS drivers (which used GAS). AFAIK, there has been a long-standing bug in LD where that linker script won't work (anymore) with .intel_syntax, but it still works with default AT&T syntax. (Yes, I've tested this a little recently.) Maybe you meant the linker was more interesting to him for .EXE, but there are various other 16-bit linkers out in the wild.

Hello kerravon,

> My plan is to get either SubC or Octogram C (both public domain, but both
> not reaching C90) to generate huge memory model code, and not use the "seg"
> keyword, so no mucking around required.

What is Octogram C, and where might I find it? A quick search engine search came up empty for me.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> What is Octogram C, and where might I find it? A quick search engine
> search came up empty for me.

https://github.com/wxwisiasdf/OctagramC

---
Glory to God for all things

> https://github.com/wxwisiasdf/OctagramC

Thanks Khusraw! Let me see if I can figure out how to use it...

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"