segmentation, paging

They look good, but having been in the beginning of this, there are some basic flaws in what the PhD's have to say.

First, segments are pretty much for code, as in "code segments."  Segments can be predefined in size, or variable, but they should always be "code segments" and never have anything whatsoever to do with data.

Some people have taken to referring to `data segments,` but that is an impossibility if you follow the aboriginal definitions of segments and segmentation.  Code is "segmented," data is not!

On the other hand, you have to differentiate between code and data, so data comes in "data blocks."  Code can also come in a "block," but that's strictly from a debugging perspective.

Data normally is in stacks, for general purposes, organized as something like arrays, and the stacks, while running, will offload the data from the stacks to some area in memory where blocks of data, data arrays and result arrays, tables, what have you, are kept.

Pages, frames, modules, all refer to specific data sizes.  That's pretty much all they do.  In general, each of these is predefined and, in general, are not variable in size.  There is a reason for this, from a programming perspective, it allows for very fast validity checking of data.

So, when you differentiate properly and do not cross definitions, a "Segment Fault," is a code error, while a "Page Fault," is a data error.

Page Faults, as you probably know, are recoverable, or Level 1 errors; one level below a "warn," and generally ignored except to enter the log of the reason for the fault, such as "Data Not Present" in any array, or "Data Not Intialized," as in data not local to the main memory [RAM] and therefore a fetch is required to peripheral memory [hard disk].

As I said, pages, frames, modules, are pretty much all the same thing and simply predefine file block sizes, something from mainframes used since core memory [donuts] was the first RAM.  The size was a "mod" or "module" and was 65,536 'words' where a a 'word' was defined as either 32 bits or 64-bits [which actually required 4- bits and 80 bits respectively of actual magnetic storage in the form of core donuts.  A core donut is simply a toroidal piece of lodestone or ceramic magnetic material with two lines of wire running through the core, or center of the donut, the X-Y Lines.  You wrote to these donuts by energizing X and Y in the same Algerbraic Summing direction, and you read them by energizing only one.  It's more detailed than that, but basically a write puts in enough current to reverse the magnetic polarity of the toroid [thus writing it], while a read only puts in enough energy to induce a counter electromotive force reaction from the toroid [thus reading it].  The number of donuts was limited by the the word size of early computers and the ability of, mostly women, to handstring these tiny donuts in a crosshatch pattern onto something resembling a computer board or card, but very much larger than today's cards; about 18 inches by 24 inches.

65,536 words, multiply by even 32, came out to be an aweful lot of donuts and these boards were expensive.  The were call "Random Access Memory" or RAM, but most just called them "core" and "core memory."

Thus, pages, frames, and a lot of other things, like packet switching maximum packet size, became oriented and predefined with the number "65,536."  And that had aborignally and always been a "mod" or a "module."

If it was code, it was a segment, and if it was anything else, like data, you could pretty much pick a name, data block, data frame, data page, whatever.  But the word "segment" itself signalled to the earliest programmers that there was a failure in execution, not in data manipulation, and at that point they would immediately call for the help of the hardware engineer.

There's a reason for everything, and no one just pulled these definitions out of some universities hat or pool of predefined "opinions," which is what the articles cited are, opinions.  What I'm stating is fact, from one of the horse's mouths, who was there when such words were invented [used is a better term, but well thought out by the earliest English professors who worked on early projects].

NYU always makes me laugh; I have to add this because New York University would hardly know a computer on site, let alone the definitions for it, they're much better at performances in Washington Square, or, at least were, at the time.

"Segment" means code.  Or at least it should, and I really don't care what Silbershatz and Galvin have to say, not a lot anyway, because they simply weren't there.

A page by any other name would still smell like a mod.

High level programming was intially done by Electrical Engineers who taught students before there was a computer sciences field [since, obviously, they were developing the field].  The students became the Software Engineers, after intially having been hired to be trained to be programmers, since the engineers already had more than enough to do and could delegate the writing of new procedures [routines, functions, the like] to a group trained especially in and for the higher level languages the engineers had written.

A Segment of code, historically, was 65,536 words of 64 bits.  There were hidden bits, 16 of them, which is also why SCSI, the emulation of mainframe cabling, had 80 bits total.  The other 16 bits were for error correction, which is an hardware concept, aboriginally, later implemented in software routines and algorithims.  Mostly, you could lose one bit in transmission over the cables and fix it, a one bit error, and you could detect worse failures, 2 bit errors and beyond.  There is a reason for everything.

If you take 65,536 and multiple it by 64, 2^16 X 2^ 7 you get 2^23 which was, at the time, about the maximum memory you could have standing as RAM in four Memory Storage Modules of 1 megaword each.  So that each Memory Storage Module contained a fantastic 1 million words of RAM storage capacity.  That machine was still at least a million times faster than the most advanced PC today, with only 4 meg of RAM!

And that is about a level 1300 class, in case you need to know.  Four years beyond a doctorate and four years beyond a Los Alamos project funded by the Defense Advanced Research Projects Administration.

From the designer's lectern.

Hi GinEric,

That  was quite an insight into evolution of computers ... While I do not have the experience and first hand knowledge of evolution, there are a few things which I don't quite agree upon.

>Some people have taken to referring to `data segments,` but that is an impossibility if you follow the aboriginal definitions
>of segments and segmentation.  Code is "segmented," data is not!
Segementation here refers to segmentation of memory ... A memory segement could hold data or code. Paging and segementation have evolved and so has the terminology associated with them. Data segement sounds perfectly valid to me in the context in which this question was raised. It might have been meaningless in those days, but it is very much standard term as of today.

>So, when you differentiate properly and do not cross definitions, a "Segment Fault," is a code error,
>while a "Page Fault," is a data error.
What if a page that contains code is not in memory and causes a Page Fault?

Cheers!
sunnycoder

Thanks for answers, I will read it in detail later because I have little time now.
(The java applet for paging is nice.)

The entire point:  A segment should never contain data.

That way, the engineer knows that the fault is in the code, and not in the data.  There is a reason for strict definitions.

Yes, many refer to data segments, which now confuses the issue: is it a code problem, or is it a data problem?

Code is not supposed to be in data areas and vice versa, and associative memory, lex levels, stacks both data and code, are built around these concepts and these concepts are implemented in hardware, with such things as tag bits, data valid bits, unitialized operand bits, etc..  Crossing definitions leads to the entirety of incorporation at the hardware level being fairly useless at a first glance because now you don't know if the problem is in the code or in the data.  The machine did, and was willing to tell you so, but it got overridden by the new broader definitions which are going to now cost you more troubleshooting and down time while you figure it out, instead of having the machine figure it out millions of times faster than you can.

It's a lot more technical than that, but that was the basic reason for the differentiation in the strict terminology.

In that respect, I could argue, quite successfully, that paging and segmentation have "devolved."

Those days:  no one has quite caught up to "those days" yet, including Intel, AMD, Microsoft, and others, they are just now learning these designs and architectures.  64-bit design and architecture from about 40 years ago now, in "these days."  Imagine where the people from "those days" are at these 40 years later!

If standards are lower "these days," too bad.  It's my pro text that conflicts with others con text, isn't it?  I marvel at the blue screens of death which are confused about what caused an error, using the broader definitions and not sticking to accepted practices.  Was it hardware or was it software?  They don't seem to be able to tell as quickly anymore.  I would blame that on poor definitions, not on the context.  Okay, so now a generator is an alternator, okay, I'm not going to argue that with someone who wants it to be that way.  NYU can go on telling tall tales, not my problem.

ciao

Thanks for more information,
I have read the book Operating System Concepts and I think that segmentation is the way how to map logical addresses into physical addresses which can contain instructions or data. Segmentation helps to suppress internal fragmentation. The segments contain various parts of programs (sqrt function, main program, symbol table, stack, array, ...). So in physical memory must be both data and instructions.
My practical knowledge is not so great, so I'm not able to argue with you, maybe sunnycoder.

Here is what a typical segment looks like in a 64-bit system [comprised of 48 bits of operand, 3 tag bits, 12 bits of error correction code parity and one overall parity bit:

ECC                        [ Overall Parity       Tag]    
xxxx xxxx xxxx xxxx   [P                         TTT     0000 0000 0000 0000    0000 0000 0000 0001

Ignoring the ECC and P, for 51 bits we have:
Tag :    Segment Descriptor
   3  :    1100 0000 0000 0000    0000 0000 0000 0001
Translated:
Tag :    
   3 :    C000 0001

You may recognise this as a semblance to the Microsoft Error Codes, and there is a good reason for it, both point to a code segment using the Segment Descriptor form.  Normally, this is a local address, that is, it does not extend out of main memory [RAM].  When the segment descriptor is expanced to its double precision [or more] segmented array descriptor, this main memory address is "Associated" with a virtual memory address, the Charlie or "C" in the most significant portion of the code segment descriptor above representing a Virtual Address element.

There are thousands of schemes and thousands of variables, as well as thousands of ways to describe the memory space, but they all hinge on a differentiation between code and data.  The Data Descriptor will have a Tag of 5 : 101

In this way the hardware itself is fully aware of what is code and what is not, and the purpose of doing that is for the finest error detection and correction, and failing that, the most accurate way of differentiating failures between code failures and data failures.

A simple data invalid is detected by a Tag of 6 : 110  which says that the data is not valid, and/or a Tag of 4 : 100 which says that the data was never initialiazed.

These two will cause a Page Fault and request a fetch from Virtual Memory [some peripheral somewhere] of Valid and Initialized Data.  This is why a segment fault is not a page fault!  Page Faults are level one faults that can be fix [corrected] and are a normal part of programming; Segment Faults [which imply that the code failed] are level 2 and level 3 faults that generally cannot be fixed unless a simple one bit error has occurred and and the ECC can fix it, or, a refetch of the code segment reloads a valid code segment.

Segmentation is segmentation of code for the purpose of aligning it within local memory using an associative addressing scheme, and associtive memory, usually some form of Lexicographical Level ordering, and Display Registers.  You might think of it as dividing the L1 and L2 cache up into strict areas of one for code and one for data.  The Associative Memory is, in general, a memory that takes an address and reads out a display register based on the lexicographical level [determined by the register number embedded in the associative address itself] which then produces the local memory address for the requested code segment which is, by the way, either Present or not Present [the Data Present Bit, or, Presence Bit, another bit in the Operand field of the word, usually bit 47, whilst bit 48 is the Sign Bit, bits 33-46 the exponent and bits 0-32 the address or Value, depending, really, on how you define the schema, but that schema is defined in hardware, not software, and software must comply with these definitions].

As I said, Intel, AMD, and Microsoft are just learning these concepts.  In fact, the company that designed it all, Unisys, when it was Burroughs under J. Presper Eckert's leadership, has recently partnered with all of them and that is because Unisys' progenitors, like the Eckert Family, John Mauchly's family, and a great number of their colleagues and proteges still own the copyrights and patents to all of these creations and inventions.  That means they will own them for at least the next 70 years, some a little longer as we're not all "dead" just yet!

You're close on one subject, segments describe some such things as sqrt, and other operators which must be implemented as a procedure [function in Dennis Ritchie's terminology which he learned from the above before he authored C].  But more basic than that, it was J. Presper Eckert's idea for the first subroutine, ever.  So, each "segment" should be a fully independent function defined somewhere in source code and compiled into a code "segment."

That is the true idea of segmentation; segmenting code into reusable blocks called segments.  A segment is a bit more than just a function in that it can stand and run independent of its caller, usually the Operating System, but if the Name is known, any program with sufficient privilege can call the code segment.  Notice how this defines down the failure area if a segment fails.

The man was a true genius.  If a segment failed, he would just swap out that segment with a newly compiled version to see if the code failure had been fixed in a rewrite and recompile as a dynamic object.  These were the very first dynamic objects, long before C, Cobol, and others were even thought of.

The reason for the linker, it could and does calculate the address of the pointer to included objects, such as dynamic objects, as in Dynamic Link Library.  It's more than that, and goes much deeper than the simple .dll does, but all dynamic and object oriented programming must use a linker to link pointers to relative and relocateable code.  The entire schema is know as Relative Addressing and such code can be loaded anywhere and will either relocate itself or be relocated by simply changing the pointer and not using any hard GOTO statements, which are eliminated in higher level languages, all branches and jumps are now relative.

Relative means you need a base address, a descriptor, and/or a pointer, as in the code segment Base of Stack, Segmented Array Descriptors, and Segment Descriptors.

The Associative Address, Lexicographical Level Ordering, and Display Registers are enhancements to the Relative Addressing and Relocateable schema.

But if Segmentation is newdefined to include Data, it breaks all of the advantages of this system hardware design, which is the true Systems Architecture Design, especially for software which must always adhere to the hardware definitions first or it will not work.

And maybe that's why current programmers have failed to get rid of their timing and other problems in their new 64-bit drivers, they are simply refusing to listen to the designers of the hardware who are telling them that segmentation is an hardware design concept, not a software concept!

You know, Harvard, M.I.T., and NYU, failed in their first attempts at building a working computer; perhaps they should listen to those at the University of Pennsylvania who did not fail in their first attempt to build a working computer.  Maybe, if they lay aside their academic jealousy for a bit they will learn something.  I like NYU, I lived around the corner on Lafayette Street near the Square for a while.  I like Harvard, although I turned down both their full scholarship and that of M.I.T., but I worked with their best engineers, all of them.  They, at least, were willing to listen to and discuss ideas, and fully incorporate them if they were advantageous.  Many grads are not so apt to behave thusly, but will insist that their definitions are correct, even in light of a challenge from the orginal designers.  It's silly, isn't it?

The first thing to do is to open their minds, maybe, just maybe, I'm right and it works better my way, which is the way of the guys who designed the first 64-bit systems and the first Operating Systems, including all of these so-called new innovations, multiprocessing, multithreading, pre-processing, look-ahead logic, restartable code, and much, much, more.  All of which are well over 30 years old already and just newly arriving on the microprocessor scene.

And so is the software and the Operating System Concepts and Theory of Operation.  And it is Intel, AMD, Microsoft, and more than a few professors and grad assistants and students that are still living in "the old days."  I have to teach them every day.  I dread teaching them the current Operating System Theory of Operations and current hardware design concepts because the books they have are seriously dated or shallow.  What if I told you that current design was Operating System and Hardware Independnet, that is, it doesn't matter what the Operating System is, nor the hardware design, because the state of the art design will adjust itself to run on any platform on any hardware?  Would you believe it?  Suppose I said "This code will compile regardless of the language it is written in and will run regardless of the hardware it is run on" would you believe that?  This is actually where the state of the art stands today, fully indpendent of hardware and/or software.  Truly portable, you plug it into anything and it runs.

Sounds impossible, doesn't it, but it's fact, not fiction.  That is what's happening "these days."  Not only can it run on C, A, Cobol, Algol, Espol, and other compiler oriented systems, it can run on mainframes, microprocessors, and in any environment whatsoever, including a compiler that fully understands any complete human language, such as English as well as any higher level language and any machine code and machine language.

Pretty impressive huh?  Where are the books on it?  Well, they are being written for this and the next generation of engineers and programmers.

But in those books you will find that segments are code and data comes in blocks, not segments.  That's how we see it.

I have a lot of things to learn yet.
It would be better to learn things more practically or at least in parallel with general concepts. But our school prefers "abstractions" of all kinds and the bowels of things remain hidden. I don't like it, but time passes so quickly and school hasn't time to learn us everything. And moreover, many things are proprietary and curious people will never know how things work (e.g. graphical cards, software design methodologies ...)