skef@cmu-cs-spice.ARPA (Skef Wholey) (02/25/85)
From: chuqui@nsc.UUCP (The Phantom)
...there really isn't much that a 32bit address gives you that a 24bit
address doesn't also give you in a manufactured product EXCEPT a marketing
tool.
If your operating system and VM hardware let you have sparse virtual address
spaces, there's a world of difference between 24 and 32 address bits. When
one can carve up his address space in any way he pleases, those extra address
bits can mean the difference between clean, efficient storage allocation and
contorted, inefficient storage allocation.
It's true that in Vax-like VM systems, where your address space must be
divided into relatively few contiguous segments, one is very unlikely to
run into any difference between 24 or 32 bit addressing. But programmers
on such a machines have to live with the fact that all their storage
allocation has to follow more or less a stack discipline.
With a large address space, I should be able to allocate and deallocate stuff
anywhere I want without penalty. Sparse addressing lets me do that. I can
have lots of tables grow very large without running into each other. With
a 32 bit address space, I should be able to have 16 tables that each have 256
megabytes to grow in. With a 24 bit address space, each table would have only
one megabyte to grow in. If just one of those tables becomes larger than
that, then I'm screwed.
Very large address spaces have distinct advantage over smaller ones if sparse
addressing can be employed. If not, few people are going to notice. But the
combination of big and sparse makes a lot of things easier.
The place where all this hits home for me is implementing Lisp. Franz Lisp
and Common Lisp on the Vax go through a good bit of contortion to do things
like allocate large arrays and do garbage collection in one contiguous chunk
of pages. Common Lisp under Accent (on the Perq and soon other machines) has
a very clean storage allocator and garbage collector that takes advantage of
Accent's support for sparse address spaces.
Some non-Lisp uses of sparse addressing are co-routine stacks and big I/O
buffers. There are many, many, others, I'm sure.
--Skef
--
uucp: ...!seismo!cmu-cs-spice!skef
arpa: skef@CMU-CS-Spiceross@dsd.UUCP (Evan Ross) (02/27/85)
> > ...in Vax-like VM systems, where your address space must be > divided into relatively few contiguous segments... Forgive me if I'm wrong, but the VMS services $cretva and $deltva allow you to create (delete) virtual pages anywhere in your address space, not just at the boundries of the control and program regions. -- Evan Ross decwrl!amd!fortune!dsd!ross "To oppose something is to maintain it. To oppose vulgarity is inevitably to be vulgar."
josh@v1.UUCP (Josh Knight) (02/27/85)
> > > From: chuqui@nsc.UUCP (The Phantom) > > ...there really isn't much that a 32bit address gives you that a 24bit > > address doesn't also give you in a manufactured product EXCEPT a marketing > > tool. From: ...!seismo!cmu-cs-spice!skef > If your operating system and VM hardware let you have sparse virtual address > spaces, there's a world of difference between 24 and 32 address bits. IBM ships processors with 128 Meg of main memory. I know of applications in IBM that are running out of VIRTUAL address space with 24bit addressing. 32 (or 31 if you're worried about a 370/XA, or if you're speaking about user space on a Vax) bit addressing isn't just for "sparse" use of the address space. Processors already need to address more than 24 bits worth of main memory and programs will use more than 24 bits worth or virtual address space WITHOUT spreading the data thinly over it. "The biggest (and most common) mistake that can be made in a computer design is that of not providing enough address bits for memory addressing and managment" Bell and Mudge, "The Evolution of the PDP-11" in _Computer_Engineering,_A_ _DEC_View_of_Hardware_Systems_Design, Digital Press, 1978. Any opinions (stated or implied) or errors (obvious or subtle) are mine, not my employers. Josh Knight, IBM T.J. Watson Research josh at YKTVMX on BITNET, josh.yktvmx.ibm on CSnet, ...!philabs!v1!josh
david@daisy.UUCP (David Schachter) (02/27/85)
...!seismo!cmu-cs-spice!skef points out that 24 bit address spaces can be
painful (compared to 32 bit address spaces) for some applications, such as
LISP processing. However, of the large number of MC68020s (32 bit address)
and NS32032s (24 bit address) that will be shipped, how many will go into
systems running LISP? How many into commercial data processing (COBOL, COBOL,
COBOL) in which the 24/32 distinction is uninteresting?
Chip designers have to make many trade-offs. It appears that National chose
speed-to-market and manufacturability.. Motorola chose prettiness. Time will
tell whose strategic planning department chose better, three or four years ago.
[The opinions contained in this article do not necessarily reflect the opinion
or policy of Daisy Systems Corporation. They are soley the responsibility of
the author who would be happy to hand the buck to some other poor slob if he
could get away with it.] {Hear no evil, See no evil, Ship it.}guy@rlgvax.UUCP (Guy Harris) (03/02/85)
> Chip designers have to make many trade-offs. It appears that National chose > speed-to-market and manufacturability.. Motorola chose prettiness. I don't know when the 320xx and the 68012 came to market, but Motorola is already making chips which support 32-bit addressing, namely the 68012 (same underlying chip as the 68010, but not in the same 68000-compatible DIP package). (Just to make sure it works, I "telnet"ted to a 68012-based machine upstairs; it does.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
ravi@eneevax.UUCP (Ravi Kulkarni) (03/02/85)
I am getting a little confused. It seems that we are talking about 2 different things here, real addressing space and virtual addressing space. I think the complaint was the limitation of 16 Mbytes of virtual memory on the 320xx series not the limitation of real available physical memory. In fact with an mmu the 320xx series has 32 Mbytes of real memory although the virtual process size is still 16 Mbytes. One question I had is does unix support a scattered virtual space. I suppose it can be done if your program is smart enough to allocate space itself. But is the loader capable of initializing a scattered space without trying to allocate swap space for the entire range? -- ARPA: eneevax!ravi@maryland UUCP: [seismo,allegra]!umcp-cs!eneevax!ravi
rpw3@redwood.UUCP (Rob Warnock) (03/03/85)
Josh Knight <v1!josh> quotes: +--------------- | "The biggest (and most common) mistake that can be made in a computer design | is that of not providing enough address bits for memory addressing and | managment" | Bell and Mudge, "The Evolution of the PDP-11" in _Computer_Engineering,_A_ | _DEC_View_of_Hardware_Systems_Design, Digital Press, 1978. +--------------- (That's on page 381, for any interested.) Turn the page (to 382), and they say: "In retrospect, it is clear that another address bit is required every two or three years, since memory prices decline about 30 percent yearly, and users tend to buy constant price sucessor systems." So if you are designing a processor family to last at least a decade, add AT LEAST 5 bits to what you think is "reasonable" now (more, for safety). I personally think we will see people complaining about 32 bits (based on real needs) BEFORE the current decade is out. Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
jeff@alberta.UUCP (C. J. Sampson) (03/03/85)
In article <295@cmu-cs-spice.ARPA> skef@cmu-cs-spice.ARPA (Skef Wholey) writes: >If your operating system and VM hardware let you have sparse virtual address >spaces, there's a world of difference between 24 and 32 address bits. When >one can carve up his address space in any way he pleases, those extra address >bits can mean the difference between clean, efficient storage allocation and >contorted, inefficient storage allocation. > >With a large address space, I should be able to allocate and deallocate stuff >anywhere I want without penalty. Sparse addressing lets me do that. I can >have lots of tables grow very large without running into each other. With >a 32 bit address space, I should be able to have 16 tables that each have 256 >megabytes to grow in. With a 24 bit address space, each table would have only >one megabyte to grow in. If just one of those tables becomes larger than >that, then I'm screwed. Ah, but if you are using vs(n) implementation, this whole thing doesn't really matter. Every process has a full address space that starts at 0, and the MMU maps any page in VM to the correct page in real memory, and then pulls the data out of it. You can grow as much as you like because you have the whole address space. The only way 24 bits is going to get you in trouble here is if you have something that grows to bigger than 2^24 bytes of memory. (Don't laugh. Look at what happened to the IBM 370.) Since the National MMU supports vs(n), there should be no problem here. If you use vs(1) anyway, you are doing it the wrong way to begin with. ===================================================================== Curt Sampson ihnp4!alberta!jeff --------------------------------------------------------------------- "It looked like something resembling white marble, which was probably what is was: something resembling white marble."
hammond@petrus.UUCP (03/05/85)
I have no objections to simply bringing less than the full 32 bits off of the chip. What I do object to is simply saying that one should be careful not to use the upper byte of an address. On the 68000, 68010, 68012, 32016, and 32032 the chip should be designed to provide some sort of trap if a memory address was invalid. On the 32016 and 32032 this could simply be a test that the upper byte is all zeros. On the 68k series, the MSB and the 23 lowest address bits should have been brought out, since the absolute short addressing mode was signed. Then the test would have been that the 24th through 31st bits were either all zeros or all ones. Note that leaving this test to the software is relatively painful, at least if you're programming in C or assembler. I'm willing to bet that the vast majority of code running on 68000's is in fact in those two languages. Probably on the 32000 series also. Rich Hammond [decvax | ucbvax | ihnp4] ! bellcore ! hammond
david@daisy.UUCP (David Schachter) (03/07/85)
In article <295@cmu-cs-spice.ARPA> skef@cmu-cs-spice.ARPA (Skef Wholey) writes: >With a large address space, I should be able to allocate and deallocate stuff >anywhere I want without penalty. Sparse addressing lets me do that. I can >have lots of tables grow very large without running into each other. With >a 32 bit address space, I should be able to have 16 tables that each have 256 >megabytes to grow in. With a 24 bit address space, each table would have only >one megabyte to grow in. If just one of those tables becomes larger than >that, then I'm screwed. If you are writing prototype software, fine. If you are writing commercial software, you had better worry about tables running out of space, no matter how big the address space. Otherwise, you will be selling a program that demos fine but breaks when customers give it input different than what you expected. (They always, always do, God bless 'em.) The software I write has to run on a machine which usually has only two to four megabytes of physical memory but a virtual address space of about a gigabyte or so. (It is an Intel 80286.) My programs generally allocate tables of a few kilobytes and then grow them as necessary. That is, I keep track of how many entries in a given table are used and how many are avail- able. When I have to add another entry to a full table, I allocate a bigger chunk of memory, copy the original to the new chunk, delete the old chunk, and fix up my various pointers, indices, and maxima. Software that allocates fixed-size tables has limits. Software that checks for filled tables (or arrays or structures or whatever) and handles such cases appropriately has fewer limits. The size of the address space isn't an issue. (By the way, the 80286 has an address space of 16k objects per task of which 8k are global to the CPU and 8k are local to the task. Each object can be up to 64kB in size, an unfortunately small amount. Objects can be protected in a somewhat flexible way. The number of tasks is unlimited. Transfers between tasks can be protected in several ways of varying complexity. Objects can be shared between tasks. Parts of objects can be shared. Shared objects can have different access rights between tasks. For example, an object might be a code segment (therefore non-writable) to an application task but it could be a data segment to the swapper task. The 64kB limit on object size can be hidden by compilers for a minor speed penalty. Intel Fortran and Metaware Pascal provide this hiding. They will also generate faster code if the pro- grammer provides assurance that the object is smaller than 64kB.) ("Intel" and "Metaware" are probably trademarks of the respective companies.) [The opinions expressed in this article do not necessarily reflect the official policy of Daisy Systems Corporation, its employees, or subsidiaries. Opinions expressed herein are the sole responsibility of the author, who is in the mar- ket for a roommate to share a two-bedroom apartment in Mountain Views, CA (hint, hint.)] {"Moscow in flames; missles headed towards London. Film at eleven."}
davet@oakhill.UUCP (Dave Trissel) (03/07/85)
In article <303@petrus.UUCP> hammond@petrus.UUCP writes: >I have no objections to simply bringing less than the full 32 bits off of >the chip. What I do object to is simply saying that one should be careful >not to use the upper byte of an address. > >On the 68000, 68010, 68012, 32016, and 32032 the chip should be designed >to provide some sort of trap if a memory address was invalid. > The original MC68000 has always had all 32 bit address lines on the die including bonding pads. Of course, the packaging problems of the times precluded the availability of all 32 address lines externally. At that early date it was too premature to tackle the problem of the missing address bits since future MMU and pinout configurations could not have been foreseen. However, during later M68000 family developments we still chose to ignore the case of the "dirty bits" in the high order portion of the address. This is because the issue rarely came up as a concern by our customers. Off the top of my head I can think of three situations where dirty bits can occur: 1) a pointer variable is set to garbage via a programming error 2) an invalid subscript causes the generation of an illegal address and 3) by software convention high order bits are used for some purpose Note that all static addresses via assemblers, high level languages and linkers should never be dirty since they are verified before execution ever commences. Therefore, we are left with the dynamically generated cases of 1 and 2 above. Of these cases, a certain amount of "wrong" addresses will not fall outside of the 24-bit addressing range. These pointers must depend on an MMU to trip them up or for "wrong alignment" exceptions to occur. Notice that if the bad pointer points within legally accessable ranges there is nothing that the architecture can do to detect errors here. Subscripts, on the other hand can be completely checked by comparing bounds before usage. Both the Motorola and National families have instructions to do this and of course regular compare and branches can be used here also. This checking requires extra overhead, though, so its a tradeoff which the user must decide upon. If no subscript range checking is used it would seem to me that most invalid subscripts would occur near the array itself and usually well within the 16 Megabyte physcial address space. Now I am not saying that there is no need for such dirty bit checking. It is obvious that there are definite programming errors which would be caught by it and microprocessors would be that much more robust. I'm just saying that most of (Motorola's) customers just haven't seen fit to complain about it and consequently we haven't seen fit to fix it. (The problem disappears with the MC68020.) Concerning case 3 above, back in the early days (all of four years ago) I can see where someone may have wanted to cheat and use the extra bits in the top of the address. After all, there weren't any >24 bit plans on the horizon and 16 Megabytes of physical address seemed unlimited (no virtual memory yet.) However, nowhere in the M68000 family literature is there any indication that a programmer is allowed to use these bits for anything other than a legal address. I compare this problem to that of BCD arithmetic. The MC68000 provides several BCD operations, however it does NOT verify that each byte of two BCD digits are actually valid decimal numbers. Now, in the future we may want to make BCD more robust and have these instructions verify the data being used. I would submit that it would be foolish for anyone to intentionally set funny flags in their BCD numbers 1) because the current instructions are not garanteed to work correctly and 2) validity checks may foil such schemes in the future. I don't see any difference between this and the dirty address bits above. >.. that leaving this test to the software is relatively painful, at >least if you're programming in C or assembler. I'm willing to bet that >the vast majority of code running on 68000's is in fact in those two >languages. Probably on the 32000 series also. Again in summary: I don't think that that many of the errors encountered would be caught by detecting illegal addresses at the high end of the address map. CHECK instructions are available for subscripts and pointers can only be partially checked via MMU protection schemes. Of course, comments welcomed. Motorola Semiconductor Inc. Dave Trissel Austin, Texas {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!davet
res@ihuxn.UUCP (Rich Strebendt) (03/08/85)
> There are quite valid reasons for using the un-used top eight bits > on [ an address ]. > Two examples of why one would want to use the top eight bits of address: > 1) A ROM monitor for the 68000 would like to intercept and print > a message for all 256 exeptions, identifying the exeption number. > This can be done by loading all vectors with the address of > the error handler with the exeption number in the top eight > bits. Without using this technique, 256 separate interrupt routines > occupying at least 1K of ROM would be required. > 2) Using the top bits for type information can be VERY attractive > in a Lisp implementation. On machines without unused address > bits, this is often simulated by allocating all objects of one > type from one pool of memory (or various variations on this). > The simulation isn't as good as really having unused address > bits however... NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO !!!!!!!!!!! Back in antiquity the IBM 360/67 used full 32-bit addresses. Its less endowed sibling, the IBM 360/65 used 24 bit addresses. It became desirable to port the PL/I compiler from the /65 to the /67. It had been VERY ATTRACTIVE to the PL/I compiler implementers to use the high order byte for information because it obviously was not going to use that byte for address. Result: "24-bit addressing mode" on the /67 and a hell of a lot of work for people to convert programs designed for 32 bit addressing (lots of virtual address space) to 24 bit addressing (make sure the high order byte is cleared after instructions like Translate and Test which behaved slightly differently in the two different modes). Soooooooo. If a block of 32 bits is DEFINED as the size of the address field for an instruction, regardless of how many are actually USED, keep your @*$$#@ fingers off of the unused bits. As certainly as the daily sunrise, someone will have to port that code to a version of the machine in which those bits ARE used. If you have been clever and were seduced by the attraction of using those bits to spiffy up your implementation, you can be certain that those who follow you will loudly express unkind opinions about your ancestry. Rich Strebendt ...!ihnp4!ihuxn!res
jss@sjuvax.UUCP (J. Shapiro) (03/08/85)
[Pacman's revenge...] It has been suggested that with the MMU, the 320xx chips allow 32 Mbytes of process space. This is true, but misleading. The A24 line is determined by a bit set in the MMU, and unless the operating system provides you with the ability to set that bit (it is intended for supervisor address space protection), you are out of luck... Also, unless you do some funky stuff with the page tables, setting that bit will suddenly cause the processor to have trouble finding your code... The right answer to 32 bits is to use the 68020 or 68012 if your need is immediate. Also, check out the NCR/32 series. If your need is less immediate, hold off until the 32532 appears. It looks as though that will prove a very interesting chip. In the meantime, I can think of many things I can do 24 bits that I can't do on a Macintosh. I can also think of things I can't do on a VAX unless it is in single user mode.... Jon Shapiro Haverford College
gda@unc.UUCP (Greg Abram) (03/08/85)
>> What I do object to is simply saying that one should be careful >> not to use the upper byte of an address. >> >> On the 68000, 68010, 68012, 32016, and 32032 the chip should be designed >> to provide some sort of trap if a memory address was invalid... > >I think this is going a bit far. There are quite valid reasons for using >the un-used top eight bits on a 68000. The only gain from the error check >would be the detection of programs which unintentionally use the top bits, >which looks like it must be fairly rare to me. Well, at least one more: Transportability, if and when the machine is augmented to allow more than 24 bits of address. Ask the IBM people about this; played havoc with their software when they went to the longer addresses. I have in fact heard an original 360 architect label their failure to trap this a great mistake. And the failure (I think) of a Load Address instruction to zip out the upper 8 bits.
tmb@talcott.UUCP (Thomas M. Breuel) (03/09/85)
> > 2) Using the top bits for type information can be VERY attractive > > in a Lisp implementation. On machines without unused address > > bits, this is often simulated by allocating all objects of one > > type from one pool of memory (or various variations on this). > > The simulation isn't as good as really having unused address > > bits however... > > NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO !!!!!!!!!!! > > [...] > > Soooooooo. If a block of 32 bits is DEFINED as the size of the address > field for an instruction, regardless of how many are actually USED, > keep your @*$$#@ fingers off of the unused bits. As certainly as the > daily sunrise, someone will have to port that code to a version of the > machine in which those bits ARE used. If you have been clever and were > seduced by the attraction of using those bits to spiffy up your > implementation, you can be certain that those who follow you will > loudly express unkind opinions about your ancestry. If I can increase memory utilisation in a symbolic language by 30% without work and without making it slower, then by all means I do it, regardless of whether it involves putting tags into pointers. In particular I do it when the program is supposed to run on a micro with maybe 1/2M real memory. The other approach to implementing tagged pointers, namely a spaced heap, is equally unportable. If you try to port something like 'CProlog' or 'Franz' to anything without virtual memory (e.g. a PDP-11) you run into a lot of trouble as well. With just 64k of address space, allocating megabytes for different heaps in 'virtual memory' just doesn't work. Storage allocators will always be system dependent if they are to be efficient. And in a programming language like LISP, the storage allocator better be efficient. The only approach to writing portable software is to follow the rules of data abstraction, information hiding, and modularisation strictly, not to make your programs so inefficient that nobody cares to port them. Thomas.
tmb@talcott.UUCP (Thomas M. Breuel) (03/09/85)
> I hear Apple is using the top byte on the Macintosh addresses. Seems like > this is going to make it difficult for them to port their software to the > 68020. Seems to me that using the upper byte of a 68000 address is just I doubt that using the upper 8 bits will give problems in porting MacIntosh software: -- use of the upper 8bits is in most cases hidden in the ROM (i.e. most applications don't even know about it). -- the 68000 already uses all 32bits in address calculations. The only way you would have to modify the code using the upper 8bits is if you have more than 16M of memory or a memory management unit which objects to bits 24-31 being set. Thomas.
nishri@utcs.UUCP (Alex Nishri) (03/10/85)
In article <181@redwood.UUCP> rpw3@redwood.UUCP (Rob Warnock) writes: >So if you are designing a processor family to last at least a decade, >add AT LEAST 5 bits to what you think is "reasonable" now (more, for >safety). I personally think we will see people complaining about 32 bits >(based on real needs) BEFORE the current decade is out. I am a regular attendee at SHARE (the large IBM computer user's group with over 1,500 member installation from six continents.) Many of the people there are running 370/XA machines, which provide 31-bit virtual address spaces. There is already a small, but growing group who have run out of virtual address space despite the 31-bits. One person I have met at SHARE works at Lockheed and regularly runs algorithms which require multiplication of matrices which do not fit in a 31-bit address space. A recent combined SHARE and GUIDE Language Futures Task Force (SHARE SSD #339) says in part, "The limitations in dealing with large programs and large data collections in large memories are both intellectual and technical: people in the data processing community are not generally accustomed to thinking that way, and the available programming tools and techniques are not adequate. The Task Force believes that no changes should be needed to the high level languages in order to deal with large data collections being used as though they are entirely contained in memory. In fact, we believe that it may be more a matter of removing restrictions, rather than adding extensions to the languages. Historically, many design limits and restrictions were imposed by yesterday's small memories (e.g. buffer sizes, limited number of optimizable variables, etc.) All such hardware-dependent and device dependent restrictions should be removed." The report goes on to discuss the fact the distinction between arrays and files is somewhat artificial and induced by hardware limitations. It discusses such concepts such as persistent arrays and their advantages in application programmer productivity. Having humans write programs that have to manipulate large data objects out of files instead of memory can often take up large amounts of time -- all because memory is too limited in size. Alex Nishri University of Toronto, N 43 38'33" W 79 23'14" UUCP: ...utcs!nishri BITNET: alex at utoronto PHONE: 1-(416)-978-7109
mikeb@inset.UUCP (Mike Banahan) (03/22/85)
To (probably mis-)quote a well known axiom of computing:
"There are only three sensible ways of allocating any resource:
to have none of them
to have only one of them
or to have more than enough"
It goes for registers, segments, address bits or anything that you like.
A shortage of a resource forces concentration on why it is needed.
Sometimes this is a good discipline, sometimes bad. I remember an ALGOL60
compiler which supported the full language and ran in 4k (yes, no mistake)
bytes on a PDP11; that was because there were only 8k of them available
and it needed some headroom for the stack.
I also remember a FORTRAN compiler for the same machine that took some 50
odd k just because of the overlaying it had to use; without
an arbitrary and unnatural constraint on its storage requirements
it would have got by in far less. The restraint was good, in that it
concentrated the mind of the ALGOL compiler writer who might otherwise
have got lazy, it was just a d****d nuisance for the FORTRAN hacker.
The UNIX (a very chauvinistic) community would do
well to look at MULTICS (or 4.xBSD and vread
vwrite) and to contemplate why files exist. Why are they there?
They are an unpleasant fix to the lack of an unconstrained segmented address
space. Read and Write are a hack around the `obvious' solution of
attaching to a named address space and assigning to or accessing the
value of the notional structures that it contains; be they bytes or
records. Why use lseek(2) when you could have pointers?
There is no solution. The best thing that could happen would be to have
ann infinite number of segments with an unlimited address space in each.
The feasability of this is nil. All other arguments are simply those
of which compromise is best; whether it is better to be rich and sick or poor
and well, or to be comfortable but with a bit of a twinge in the back
now and then...............
--
Mike Banahan, Technical Director, The Instruction Set Ltd.
{decvax!mcvax}!qtlon!inset!mikebhenry@utzoo.UUCP (Henry Spencer) (03/27/85)
> ... contemplate why files exist. Why are they there? > They are an unpleasant fix to the lack of an unconstrained segmented address > space. Read and Write are a hack around the `obvious' solution of > attaching to a named address space and assigning to or accessing the > value of the notional structures that it contains; be they bytes or > records. Why use lseek(2) when you could have pointers? > > ...which compromise is best; whether it is better to be rich and sick or poor > and well, or to be comfortable but with a bit of a twinge in the back > now and then............... That is indeed the question. Which would you pick to sweep the world: a spiffo system (call it, say, "Multics") that runs only on rare and hideously expensive hardware, or a less-clean system (call it, say, "Unix") which definitely isn't as spiffy but runs on anything? Even if you ignore Multics's excessive second-system-effect complexity, and Unix's advantages gained from Multics hindsight, the winner is clear. Incidentally, how do you implement a pipe or a terminal as a segment? "Revolutions are won by the poor and healthy, not the rich and sick." -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/05/85)
> > I don't want to get religious, but ADA does suck and I would never use it > > for anything! > > On what evidence you base this statement? > > Have you ever used ADA, or are you just passing on other people's opinions? > If you have used ADA, please tell me why you think it sucks. If you > haven't used ADA, please keep your uninformed opinions to yourself. The answer to the first part of your question is contained in the earlier statement. No, I havent USED ADA. As I stated earlier I would never use it for anything. I have investigated the language. I dislike it for many reasons but won't go into the details. The bottom line is that ADA does not allow me to do anything that I can't do easily with my current language of choice. (Except write programs to sell to the DOD) If ADA does not allow me to do anthing that I want to do and can't do with my current lingo choice then why put up with it? Just to humor the DOD?
david@daisy.UUCP (David Schachter) (04/19/85)
Mr. Spencer asks "Incidentally, how do you implement a pipe or a terminal as
a segment?" Well, I'm just a dumb application programmer but our O.S., running
on the iAPX286, implements real, honest-to-goodness Unix pipes and devices.
(iAPX286 is a trademark of Intel Corp., Unix is a trademark of whatsleftofBell,
and most other words are trademarked by one fool company or another.)
[generic disclaimer] {n.f.q}henry@utzoo.UUCP (Henry Spencer) (04/22/85)
> Mr. Spencer asks "Incidentally, how do you implement a pipe or a terminal as > a segment?" Well, I'm just a dumb application programmer but our O.S., running > on the iAPX286, implements real, honest-to-goodness Unix pipes and devices. Of course. But if I'm not mistaken, they are not implemented as segments in the address space of processes. Which is what the original discussion was about. You can implement Unix pipes and devices on most anything; whether the machine is segmented or not makes no difference. The point is, you can map files into a process's address space on a sufficiently- cooperative machine (I doubt that the 80*86 qualifies), but it is very hard to make pipes and devices act like files if you do this. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jer@peora.UUCP (J. Eric Roskos) (04/24/85)
henry@utzoo.UUCP (Henry Spencer at U of Toronto Zoology), writing about mapping files into the address space, says: > The point is, you can map files into a process's address space on > a sufficiently-cooperative machine (I doubt that the 80*86 > qualifies), but it is very hard to make pipes and devices act > like files if you do this. Why? If you make pipes do this, then what you have is equivalent to a shared memory segment. The major distinction between pipes and shared memory in this regard is that pipes are unidirectional and force sequential access to the data (this is, in fact, a problem with a lot of the current interprocess communication schemes). If you map the pipe into the address space on the output side of one process, and into the address space on the input side of another process, then you have a shared memory segment (except that you might make it write-only on the output side and read-only on the input side in order to make it more pipe-like, to restrict the flow of data to one direction). Making devices be mapped into a process's address space actually would solve many problems. It is already done for some sequential devices, such as serial ports, on "memory-mapped I/O" machines. Making a disk be addressable as part of the address space would simplify access to it; and that is essentially how the secondary storage in demand-paging type systems works (which is probably where the idea came from originally, as a generalization of that approach). And of course, primary memory is a random access device that is almost always mapped into the address space (except on micromachines such as PE's 3200 series, where you address it in much the way you address a disk, by writing the address you want to access, then waiting for the data to become available). -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
hammond@petrus.UUCP (04/25/85)
> henry@utzoo.UUCP (Henry Spencer at U of Toronto Zoology), writing about > mapping files into the address space, says: > > > The point is, you can map files into a process's address space on > > a sufficiently-cooperative machine (I doubt that the 80*86 > > qualifies), but it is very hard to make pipes and devices act > > like files if you do this. J. Eric Roskos comments: > > Why? If you make pipes do this, then what you have is equivalent to a > shared memory segment. ... No, pipes have synchronization, which you don't get with shared memory alone. Pipes also have a "stream" semantics which shared memory doesn't have without extra user level code. > > Making devices be mapped into a process's address space actually would solve > many problems. It is already done for some sequential devices, such as > serial ports, on "memory-mapped I/O" machines. Making a disk be addressable > as part of the address space would simplify access to it; ... Wait, memory-mapped I/O is not the same as viewing a device as a segment. Mapping a disk into an address space is OK, but I am planning on getting 3 Gigabyte optical disks this year, that's 1.5 x 2**31. If I want to copy from one to another by mapping them both into memory I need 33 bits of address space!!!! Does that mean we go to 64 bit address spaces? And what does that do the average program which doesn't need more than about 16 bit pointers? I submit that the stream view of the world has the useful feature that it maps onto any size of real objects, while even 32 bit addresses will soon have objects that can't be mapped entirely into the address space and thus will require 2 (TWO) views of the world, depending on the size of the real object. Rich Hammond {ucbvax, decvax, ihnp4, allegra} !bellcore!hammond
henry@utzoo.UUCP (Henry Spencer) (04/25/85)
> > The point is, you can map files into a process's address space on > > a sufficiently-cooperative machine (I doubt that the 80*86 > > qualifies), but it is very hard to make pipes and devices act > > like files if you do this. > > Why? If you make pipes do this, then what you have is equivalent to a > shared memory segment. The major distinction between pipes and shared > memory in this regard is that pipes are unidirectional and force sequential > access to the data (this is, in fact, a problem with a lot of the current > interprocess communication schemes). If you map the pipe into the address > space on the output side of one process, and into the address space on the > input side of another process, then you have a shared memory segment > (except that you might make it write-only on the output side and read-only > on the input side in order to make it more pipe-like, to restrict the flow > of data to one direction). Precisely, what you have is a shared memory segment, requiring (potentially) many megabytes of buffering for data that is in fact being read only in a completely sequential way. Besides, how does the receiving process know when the next lump of data has been deposited at the end of the segment? Spin in a loop waiting for the off-the-end-of-the-segment addressing faults to stop? You end up with a substantial amount of specialized machinery that is relevant *only* to pipes, defeating the crucial notion that pipes "look like" normal files and programs don't need special preparations to work from a pipe. > Making devices be mapped into a process's address space actually would solve > many problems. It is already done for some sequential devices, such as > serial ports, on "memory-mapped I/O" machines. Again, sure, you can do it... but those serial ports do *NOT* look like files to the software. Once again, programs have to *know* what sort of thing they are talking to: not only that they are talking to a serial port, mind you, but exactly what the hardware looks like! This is the exact reverse of device-independence, which is what the "everything's a stream of bytes" I/O model gets you. > ...And of course, primary memory is a random access device > that is almost always mapped into the address space (except on micromachines > such as PE's 3200 series, where you address it in much the way you address > a disk, by writing the address you want to access, then waiting for the > data to become available). Actually, that is the way main memory works on most machines, at the microprogramming level. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jer@peora.UUCP (J. Eric Roskos) (04/26/85)
hammond@petrus.UUCP (Rich Hammond at Bell Communications Research, Inc), responding to my comments comparing and contrasting pipes with shared memory, writes: > No, pipes have synchronization, which you don't get with shared > memory alone. Well, not with conventional shared memory. I must admit having an unusual interest in this area, since my Doctoral dissertation was on the subject of making synchronization operations be integrated with shared memory access. A practical implementation of such a facility (it preceeded my own research, which was involved with using Dijkstra's `weakest precondition' to characterize shared memory access in order to facilitate correctness proofs where shared memory is involved) is found in the Denelcor HEP machines. > Wait, memory-mapped I/O is not the same as viewing a device as a segment. Here we just differ on our views of device access. A serial byte-stream device, such as a serial port to a tty, cannot be read randomly. You could assign "addresses" to each byte coming in, but this wouldn't do much for you, since you can't go forward and read n bytes ahead of your current character, or backward and read previous characters (unless you copy them into a random-access memory, of course). When you treat a device as a segment, you are just integrating the addressing of the device into the machine instruction set, so that the address that appears in a machine instruction (or more accurately, a memory-access operation via the user-level instruction set) can specify an address on a random-access device other than conventional RAM. The fact that primary memory is generally the only random-access device addressable directly through all the instruction set's addressing modes and instructions causes it to be perceived differently than all other devices. But it's not; it's a device like any other (subject to the usual device- specific constraints of volatility, etc, of course). The point you raised in your comments, however, is one of the major reasons why it generally is given this special status; if all the storage locations in a machine are all namable in the same name space, the number of bits required to represent the name space can be fairly large. On the other hand, you aren't required to use all the bits in all your instructions; they could, for instance, just appear in the translation tables for mapping virtual to physical addresses, with the virtual addresses having a much smaller number of bits than the physical address. This is the reverse of what we usually see now; but it doesn't have to be that way. -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
guy@sun.uucp (Guy Harris) (04/30/85)
> Mr. Spencer asks "Incidentally, how do you implement a pipe or a terminal as > a segment?" Well, I'm just a dumb application programmer but our O.S., > running on the iAPX286, implements real, honest-to-goodness Unix pipes > and devices. But does it implement them *as segments*? I.e., do you "write" to a pipe or terminal by storing data into a segment in the exact same way you'd write data in a file by storing it in a segment? Furthermore, do you "read" from a pipe or terminal by fetching data from a segment? Multics did file I/O by fetching from or storing into a segment, but I/O to devices was done by calling various device driver entry points. Guy Harris
jerry@oliveb.UUCP (Jerry Aguirre) (05/09/85)
> a completely sequential way. Besides, how does the receiving process know > when the next lump of data has been deposited at the end of the segment? > Spin in a loop waiting for the off-the-end-of-the-segment addressing faults > to stop? You end up with a substantial amount of specialized machinery > that is relevant *only* to pipes, defeating the crucial notion that pipes > "look like" normal files and programs don't need special preparations > to work from a pipe. > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Suspending a process on an address fault is the esence of demand paging. Whether the suspension is for a disk read or a memory write by another process doesn't change things. Assuming the hardware allows the segment to grow, the process can be suspended waiting for a write on the segment. Sorry, a pipe does NOT look like a normal file. Try doing a seek on a pipe! If "normal" files were memory mapped then a memory mapped pipe would look like a "normal" file. Admittedly this does not give the equivalent infinite capacity of a pipe but some way of disgarding the begining of the pipe as the end grows could be thought up. Perhaps the problem with mapping a tty line into memory is that we are looking at the wrong level. Lots of systems have memory mapped terminals. A specific character in memory maps to a specific row and column on the screen. Software to trap writes to "screen memory" and provide an optimized screen update (ala curses) would allow driving remote terminals. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry
henry@utzoo.UUCP (Henry Spencer) (05/17/85)
> Suspending a process on an address fault is the esence of demand paging. > Whether the suspension is for a disk read or a memory write by another > process doesn't change things. Assuming the hardware allows the > segment to grow, the process can be suspended waiting for a write on the > segment. Of course. But this *still* makes pipes different from ordinary files, because a read off the end of an ordinary mapped-in file is probably an error rather than a request to wait until the file grows. Admittedly, this is the sort of difference that a reasonably careful operating system could handle invisibly. That hadn't occurred to me before. Note also that demand paging is not enough, unless you're willing to say that pipes and files are always an exact number of pages long; you really need segmentation hardware that works to the byte. > Sorry, a pipe does NOT look like a normal file. Try doing a seek on a > pipe! ... "Beauty is in the eye of the beholder." The number of programs that do seeks on inputs is miniscule compared to the number that don't. (Even on Multics, virtual-memory measurements show that most files are read in a strictly sequential manner.) For the vast majority of programs, which do not try to seek on their inputs, pipes look exactly like files. > Perhaps the problem with mapping a tty line into memory is that we are > looking at the wrong level. Lots of systems have memory mapped > terminals. A specific character in memory maps to a specific row and > column on the screen. Software to trap writes to "screen memory" and > provide an optimized screen update (ala curses) would allow driving > remote terminals. This solves CRT terminals, although with some reservations about the efficiency of the solution (you'll have to try to delay until you've got a substantial number of updates for the screen, since one-char-at-a-time is often fairly expensive in characters transmitted). It does nothing for most other devices, alas. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry