On 2017-09-17 05:51, Paul Carmichael wrote:
El 16/09/17 a las 19:50, nospam escribió:
In article , Paul Carmichael
wrote:

I had an ISA memory expansion board designed for a 386 that I was able
to get working in the machine and expanded the memory to
16megs...that's
the maximum amount a 286 can address. I did it just for the sake of
doing it.

That said, would it have been possible to put 16 megs of memory in
a 286
at the time it was built, probably only Bill Gates could have
afforded it!

it might have been possible, but it wasn't particularly useful because
of segmented memory, a problem inherent to x86 back then.

I was programming back then, and XMS was useful. Not very fast
though. A lot
faster than MFM hard drives, so better than "virtual memory".

it was still a royal pain in the ass and comparing it to vm is silly.

4k pages. Not that different.

x86 didn't get a linear address space until much later.


I was an assembler programmer. Huge pointers were for girls. Real men
used segmentffset. Everything had its place and 64k segments were
plenty big enough for most stuff.

Been there. Assembler and mixed Pascal/assembler. (Even a mixed
Pascal/Fortran project - but that was on a VAX-785).
Today I use Pascal (fpc) and the 64k segment limit is happily gone. In
32 bit I can allocate 3 GB of heap w/o a worry and build monster trees
or other linked lists that allow for near instant location/sort of data
in myriad ways. If I compile for 64 bit, well, then ...

X86 never got a flat memory model. Actually, I suppose that .com
programs were flat model in their way :-)

They were limited. I had projects in the late 80's/early 90's that
needed a lot of programming care to stay inside the 64k segments. Mind
you: CS, DS, ES, SS @ 64kB each made for some fairly large program
spaces if needed on a bare bones 286 machine with enough memory.

Also Turbo Pascal supported code swapping so a careful selection of
"swappable" code sections could be handy and efficient even in a real
time case.

If you were brave and clever you could even use the opposite end of the
stack space temporarily setting ES equal to the SS and just taking care
to start at 0 and allocate upwards (which was natural for statically
assigned memory). That section of code would push the ES onto the
stack, copy the SS to ES, then use the lower portion of that segment.
Pop the ES when exiting that code block. I did that experimentally but
never in a "deliverable".