Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.applications Subject: Re: WorkBench 2.0 Message-ID: <20951@cbmvax.commodore.com> Date: 25 Apr 91 16:15:05 GMT References: <20515@cbmvax.commodore.com> <20890@cbmvax.commodore.com> <1938@manta.NOSC.MIL> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 44 In article <1938@manta.NOSC.MIL> norton@manta.NOSC.MIL (Scott Norton) writes: >In article <20890@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>That special place in fast RAM is, thanks to MMU magic, exactly the same place >>ROMs live. ROM code is not relocatable. >What impact does this restriction have on moving ROM routines to 32-bit >wide memory on machines that have it? None, really, since that has always been done via the aforementioned MMU magic. Actually, since I released the SetCPU V1.6 sources to the public domain, this bit of "magic" is no longer necessarily heavy ju-ju that no one can understand, but something fairly accessable to anyone wishing to muck around with it. >I had read that system performance really peps up when something like >layers.library is executing out of 50 Mhz, 32-bit wide RAM. Aside from the fact that memory is rated in row access time, not frequency (well, I AM the hardware guy around here), you're correct, that does indeed happen. It's all done via MMU. >I would hope that the non-relocatable stuff is startup code or other >mystical OS secrets, and not shared system libraries. Any Amiga object file is relocatable code. That includes programs, libraries, device drivers, or anything else you load from disk. All ROM code is assembled to absolute locations. This makes lots of sense if you think about it. The relocatable code isn't relocatable when it's executable, only when it's in the standard object format. When you load an object file, a DOS routine called LoadSeg() allocates some memory for the code, puts the code there, and then patches in any absolute references based on the relocation data that's supplied in the object file. For ROM, you can't exactly patch absolute references, so they must be assembled for an absolute location for any given ROM. Of course, the particular absolute location for any given routine can change any time you build a new ROM, and the Amiga library mechanism hides all the details of this quite nicely. >LT Scott Norton -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.