Re: Disk ][ Launcher (was: Late night musings...)

[nathan@visi.com (Nathan Mates)]

In article <50f1mg$ihd@nyx10.cs.du.edu>,
Will Baguhn <wbaguhn@nyx10.cs.du.edu> wrote:
>>   The GS has none of that functionality, so the only way to really
>>see if an instruction will cause a reference to the "hardware" (Cxxx,
>>plus the currently displayed screen if you're not running the code in
>>a bank that is displaying the screen) is to verify each and every
>>instruction. Anything involving only registers would be simple--- see
>>if it won't trigger a memory access, and go on from there. Anything
>>hitting an arbitrary memory address would hhave to have that address
>>checked to see if it'll cause a hit on hardware, and specially
>>processed if so.

>How about the trace interrupt?

   Sounds fine and dandy, except for two facts. 1) The GS ain't got one.
2) It's so important that I just had to mention it twice. The GS doesn't
have one. [Apologies to Red Dwarf; I know my phrasing's off here]

   Next problem: interrupts are _COSTLY_ in terms of cycles. Do a
count for the # of cycles needed to save all registers and do a
jsl. Now factor in the time to restore that state. Add in a good chunk
of overhead, and I bet you're running slower than a well-designed 100%
emulator. Yeah, using interrupts are second nature to anyone from a
x86 background, as they're they only way to get anything done. Only
when you're speed conscious do you suddenly have to stop and realize
that some things that are easy to do are really hurting you.

   I still think a (well-done) 100% emulator might be best for overall
performance; I'm not sure if the overhead in checking a piece of code
for provably zero i/o or video references would be worth it in the
long run.

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places?  -R.A. Heinlein