rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (06/21/88)
[ I'm gonna sit by you! ]
In any case, has anyone patched loadseg() to stuff code chunks in
32-bit memory, and rearrange the free memory list so 16-bit memory
gets allocated first? When I use my system, I use my system, quite
often with multiple huge programs concurrently running, and I'd
much rather have the code execute out of 32-bit memory with the
data come out of 16 (since longwords aren't aligned anyway) than
the reverse. I'd be interested in any timings people have in this
regard. Things like vd0: and ram: should *never* get 32-bit memory.
Maybe the stack could be put in 32-bit memory too, but that starts
to get a little messy.
No, I don't have a 68020, but this has nagged me for a while.
--
/-- Tomas Rokicki /// Box 2081 Stanford, CA 94309
/ o Radical Eye Software /// (TAMU EE '85) (415) 326-5312
\ / | . . . or I \\\///Join CCFFAALW---Concerned Citzens
V | won't get dressed \XX/Fighting For An Acronym-Less Worlddaveh@cbmvax.UUCP (Dave Haynie) (06/22/88)
in article <3091@polya.Stanford.EDU>, rokicki@polya.Stanford.EDU (Tomas G. Rokicki) says: > > [ I'm gonna sit by you! ] > In any case, has anyone patched loadseg() to stuff code chunks in > 32-bit memory, and rearrange the free memory list so 16-bit memory > gets allocated first? Only thing is, 32 bit memory isn't only just 32 bits wide in most cases, it's also faster than standard 16 bit memory, often by a factor of 2 or more. > When I use my system, I use my system, quite often with multiple huge > programs concurrently running, and I'd much rather have the code execute > out of 32-bit memory with the data come out of 16 (since longwords aren't > aligned anyway) than the reverse. Geesh, how many copied of TeX do you run at a time, anyway :-) It's true that longwords are normally only word aligned, so you'd only get the advantage of a 32 bit word ~ 1/2 the time with a random assortment of longwords. In my 7 meg system here, the first 4 megs of FAST memory are 32 bit memory, so I doubt in this case you'd be running out of FAST that often. However, with a smaller amount of 32 bit I can certainly see your point -- code can often make better use of 32 bit memory than data. > I'd be interested in any timings people have in this > regard. Things like vd0: and ram: should *never* get 32-bit memory. And at least vd0: wouldn't. It's getting it's memory from the end of the memory lists. Unless you tried this re-ordering scheme; then it's possible that vd0: would see the 32 bit memory as of RAM and use it before using the 16 bit stuff that's at the front. With A2620s, we never had to worry about memory list ordering, since the board's hardware defines it's 32 bit memory as being the first autoconfig device, so it shows up first in the free pool (after you put the $C00000 memory at the end, anyway). > Maybe the stack could be put in 32-bit memory too, but that starts > to get a little messy. At least system stack, interrupt code, exception vectors, and the ROM Kernel could all take advantage of living in 32 bit memory. > /-- Tomas Rokicki /// Box 2081 Stanford, CA 94309 > / o Radical Eye Software /// (TAMU EE '85) (415) 326-5312 > \ / | . . . or I \\\///Join CCFFAALW---Concerned Citzens > V | won't get dressed \XX/Fighting For An Acronym-Less World -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"