Re: Virtual Memory let loose...

John Carter wrote:


> Does anyone have experience of such systems? I have used some of these
> things on Vax/VMS Vax C, but found that using only library level
> support was painful in the extreme. (But then on ye olde Vax 750 most
> things were very painful)


Library level support is also tied specifically to the to the library
you are using and hence introduces portability problems. Of course,
any reliance on segmented memory architectures also introduces
portability problems.


While the specific capabilities of a particular target architecture
are always of interest for possible exploitation, in my world of
endeavors productions systems almost always have to run on a variety
of platforms.


Having said that, I recommend work in this area concentrate on the
"semantic" advantages of a desired memory organization scheme with the
result being an abstraction layer. By semantics, I mean producing an
abstract model of the memory architecture which can either apply
directly to a target architecture, or which can be "faked" on target
architectures which do not necessarily support it.


As far as coding language is concerned, two things are needed. The
language must provide facilities for low-level access to the target
architectures facilities. Second, the language must provide some
facility to allow the programmer to specify the storage schema desired
for individual variables. With these two facilties, the program can
then define the desired storage schema, using direct low-level access
to the target architecture, and then "attach" this schema to the
variables to which they apply.


Having stated the desire to make a new language, I shall not attempt
to persuade you to choose an existing language. However, I believe it
is beneficial to see how Ada 95 approaches these issues.


Ada 95 has low-level access facilities in the form of representation
clauses, attribution clauses, and machine code insertions.


Ada 95 also defines a precise semantic model for object allocation an
deallocation. It does NOT, however, define the implementation for such
allocation. It does require a given compilation environment to provide
at least one such scheme meeting the general model requirements and
allows the programmer to define their own schemes with "storage
pools". I've used this facility myself many times, primarily to insure
that related variables are in a contiguous block of memory. Up to now,
I've, that has been the only "extra" requirement of my storage pools,
but I could include segmentation issues into a storage pool easily.


I'd like to close with this point. We can get so wrapped up in the
specifics of what we are trying to represent with a language that we
wind up with something so rigid and specific as to be useless in a
general sense. Language facilities should include complete
descriptions of a general model and provide hooks so that model can be
extended to encompass special requirements as needed.


> Could we make implicit (within the compiler) use and explicit (user
> level) use of these features?
>
> Could we make every aggregate type a separate i*86 segment? What would
> be the penalty? Would we have to fight the operating system for
> control? Garbage collectors become easier, no need to the garbage
> collector to fiddle the users pointers after a sweep, just fiddle the
> segment descriptors!
>
> Could we allow users to create read/write barriers? Eg. Server creates
> a vast empty array. But fills the required elements "just-in-time"
> for the client to read it. When memory fills up, pages are just forgotten...
>
> What other fun toys can we create for the user?


--
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
--

Return to the comp.compilers page.
Search the comp.compilers archives again.