Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!rutgers!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: <20055@cbmvax.commodore.com> Date: 23 Mar 91 03:46:41 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> <19551@cbmvax.commodore.com> Organization: Commodore, West Chester, PA Lines: 79 <19840@cb Sender: Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Followup-To: Distribution: Organization: Commodore, West Chester, PA Keywords: In article pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) writes: >To this you comment repeating exactly what I say here, that is 32 bit >addressability is not constricting for an Amiga because its typical >applications are small and do not rely on a large sparse address space. >This is unfair! You cannot object to what I say by repeating it! :-) Who said I objected? Actually, I think you missed my point: on something other than an amiga, even if the software is bloated, it still doesn't matter until you're a) actually using 4 gig worth of memory space, and b) have at least 4 gig of swap space. (well, less if you're memory- mapping files - 4 gig disk space in that case (but you'd have to be mapping in almost all your disk!)) >jesup> But such services can be many orders of magnitude faster than >jesup> remapping. > >jesup> An example is a program I wrote and posted to comp.os.research, >jesup> concerning pipe speed versus shared memory speed to transfer >jesup> data. I merely sent a shared-memory message from one process to >jesup> the other saying the data was in the shared buffer. > >You only win if you can make assumptions about the hw environment, and >not use OS sempahores, but use hw locks. Again, it would be better >anyhow to have tightly communicating processes in the same address space >than using shared memory. Who made assumptions about the hardware environment? I merely called an OS primitive (PutMsg) which sent a message to a specific port. How it accomplishes this is irrelevant. >jesup> Rebuilding process page tables on each pass would have swamped >jesup> the actual transfer time. > >Hardly, I think, given a suitable buffer size and a quick way of >modifying two page table entries. I cannot imagine an implementation of >remapping which is significantly more expensive than an implementation >of semaphores. Again, hw locks are faster than sw remapping or sw >semaphores, but of more limited applicability. I think you underestimate page-table-rebuild time, or overestimate how fast shared messages can be. Semaphores expensive?? Hardly (at least in a single-processor environment). >And remapping after all is just something you do if you have to run >applications designed for multiple address spaces on a single address >space architecture. What I say is not that it's optimal, but that it is >tolerable. Point taken. >jesup> Messages can be shared also (greatly increases message passing >jesup> speed). > >No, the speed does not increase a lot. Unless the synchronization is >done using hardware primitives, which is nonportable, or at least not >always applicable. So long as it's hidden in the OS, I don't care if it uses blue men from mars. The OS _can_ use any hardware primitives it likes. For example, message passing on the amiga is (essentially) disable interrupts, addtail the message onto the port's list (easy with doubly-linked lists), enable, and signal the port owner's process (which may cause a reschedule if the owner is higher priority). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)