Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

nuclear war (Miscellaneous)

posted by tkchia Homepage, 16.11.2022, 18:16
(edited by tkchia on 16.11.2022, 23:05)

Hello kerravon,

> > wut? "Figure out" an API for an existing system "from first principles"?
> > How? And why?
> To understand and find out anything I am missing.
> E.g. it was only recently that I found out that
> people normally develop new systems using an
> emulator on an existing system, but DOS was instead
> developed with the aid of a "monitor". Apparently
> use of a monitor is a lost art, but I was previously
> unaware that the art even existed.
Yes, indeed, it is a good idea to find out about prior art(s). Please continue to do that.

(In contrast, it is usually not a good idea to deduce facts about the real world from "Pure Thought" or "Pure Wisdom". That way madness lies.)

> And only about 24 hours ago (part of the delay here)
> I realized I didn't know (and still don't know) how
> it is technically possible for compilers to support
> the small memory model, given that a buffer can
> reside on either the stack or in the data segment.
"Small model" in x86-16 coding simply means that there are two program segments, one for code, and one for data — and stack! So within the program you have cs ≠ ds = ss: the stack segment is the same as the data segment.

If you run a debugger on a small model program compiled by Turbo C++ or Open Watcom or some other 16-bit compiler, you will find that ds = ss by the time you reach main (). So there you go.

This is straightforward for the compiler to implement in most cases.

(*** begin long aside ***)

However, a problem arises when compiling an interrupt handler routine (via a compiler-specific interrupt or _interrupt keyword). The interrupt handler might be called in the middle of some BIOS or DOS routine which sets ss to point outside the program: then you have ss ≠ program's data segment (let us call it .data).

The interrupt handler can easily set ds := .data, but temporarily moving the stack pointer ss:sp into the program data segment is not easy, and not always possible.

It turns out that Turbo C++ (version 2, at least) kind of glosses over this issue. It assumes ss = ds = .data, without setting ss (!). But it will normally access automatic stack variables via (ss:)bp and static storage variables via other registers or addressing modes, i.e. via ds. This happens to work most of the time if you do not happen to mix stack addresses and static storage addresses. But it may fail.

Open Watcom in contrast explicitly handles this case, and will compile the interrupt handler in a special mode which takes into account that we might have ss ≠ ds := .data.

Bart Oldeman, myself, and a few other folks, had a discussion about this case (among other matters) back in 2018, when I was trying to add far function support to Andrew Jenner's gcc-ia16 toolchain: https://github.com/tkchia/gcc-ia16/issues/19#issuecomment-367183866 .

(*** end long aside ***)

Thank you!

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

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 79 users online (0 registered, 79 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum