🚀 go-pugleaf

[ "Send lawyers, guns, and money ..." ]

In article <697@mips.UUCP>, mash@mips.UUCP (John Mashey) writes:
>A pleasant thing about doing an architecture from scratch is the ability to
>forbid the use of stores into the instruction stream. [Obviously, you must
>be able to create executable code, but you can require a system call to
>indicate weird cache manipulations.]  There appears to be a fair amount of
>hardware in many high-end machines dedicated to worrying about this
>[relatively rare] event, which is too bad.  Had it been forbidden from
>day one, I suspect little performance would be lost; certainly, most
>high-level languages don't do this kind of thing anyway.

There is a related problem here with machines that have seperate
instruction and data caches, and which run s/w that doesn't distinguish
between "code" and "data" in the object/load file formats.

With large cache line sizes (64 byte lines on Amdahl 5890's), you can
frequently end up with data in the I-cache because the compiler gens
short chunks of code followed by short chunks of data followed by more
code, etc.  This also happens with some styles of coding in assembly
language.  So we end up "shuffling" cache-lines back and forth between
the I-cache and Op-caches.  And yes, you're right ... it does take alot
of h/w to do this kind of thing without incurring a (big) performance
penelty.

/kim


-- 
UUCP:  {sun,decwrl,hplabs,ihnp4}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25

[  Any thoughts or opinions which may or may not have been expressed  ]
[  herein are my own.  They are not necessarily those of my employer. ]