[PLUG] Segmented memor architecture -- Why is it bad?

[Anthony Schlemmer]

Things were much simpler back in my days of coding 8080 and Z80 assembly 
language under CP/M. With 16 bit addressing and no segments things were 
really straight forward. Later on when I got into doing some X86 work I 
never really felt comfortable with the concept of Intel's 
segment:offset crap. 

I also managed to avoid much x86 work in college as about the only class 
that used any sort of microprocessor assembly language was an operating 
system pragmatics class I took as a senior. I was relieved to find that 
our target platform for the class was a Motorola 68010 based system 
with an MMU. We did have to take an assembly language class as well but 
at the time it was IBM 360/370 assembly. It was an amazing thing to see 
IBM's assembler and our assembled programs run on our school's CDC 
Cyber mainframe which had a 360/370 emulator that was written in 
Minnesota Pascal on it.

Tony

On Thursday 30 May 2002 14:33 pm, Greg Long wrote:
> Programmers of course had to do the most work, but there were
> extensive support needs generated by Joe User who didn't understand
> why his (then high end) 32mb system didn't have enough [conventional]
> memory to run an old DOS app that installed from a single floppy
> disk.
>
> I'm glad I didn't deal with segment:offset any more than was recently
> necessary for the x86 Assembly Language Course at OIT.
>
> Greg
>
> -----Original Message-----
> From: plug-admin at lists.pdxlinux.org
> [mailto:plug-admin at lists.pdxlinux.org] On Behalf Of Craighead, Scot D
> Sent: Thursday, May 30, 2002 2:27 PM
> To: 'plug at lists.pdxlinux.org'
> Subject: RE: [PLUG] Segmented memor architecture -- Why is it bad?
>
> >Please elucidate this subject.  Why did they choose a segmented
> > memory architecture, and why is it bad?
>
> I'm surprised you don't know what this refurs to.  Maybe it's because
> the 32-bit operating systems have pretty much solved the problem. 
> Back in the DOS days, if you wrote assembly language programs, you
> cursed this daily. Memory locations were made of 2 16-bit numbers,
> the segment and the offset. This meant that there were were 6 "memory
> models" for a program.  In C, you just had to tell your compiler
> which to use, but it was a big hassle if you wanted to link in
> assembly modules to your C code.  You had the tiny memory model,
> which used 1 16-bit addess for all code and all data, for example.
> This means your entire program had to fit into 1 64K segment as well
> as your variables.  Executable files the have the extension .com are
> this way.  Then you had Small, one segment for code and another for
> data.  You can extrapolate the rest from here. To make things even
> worse, there eas the 640K barrier.  All the memory locations above
> this point were resurved by the operating system.  So that's all the
> memory you get for your applications programs.  Deal with it.  Then
> along came extended and expanded RAM.  Two different ways to do the
> same thing, have access to more memory. The only problem was that it
> was a major hassle to work with.  It is amazing that PC's became so
> huge when they were designed so poorly.  Fortunate, only programmers
> had to deal with this and Joe user had no idea.
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug

-- 
Anthony Schlemmer
aschlemm at attbi.com
>>>>This machine was last rebooted:   2 days 15:41 hours ago<<