aglew@ccvaxa.UUCP (02/20/88)
>HP does have {Compare,Move,Bittest,Add}&Branch instructions.
Better yet, HP has them patented (at least move and branch).
The mind boggles.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have nameserver
aglew@gswd-vms.gould.com - if you don't
aglew@gswd-vms.arpa - if you use DoD hosttable
aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.aglew@ccvaxa.UUCP (02/21/88)
..> Memory mapping the register file.
Sure, you can do it already! Reserve an address range for the register
file. Make these pages invalid, so you fault whenever you try to touch
them. In your page fault handler, go and actually fetch from the
register file (which you have probably saved on the stack when you took
the exception).
Clunky? Yes, but not much more so than other techniques for mapping
the register file, and probably with less impact on performance if you
don't access through maps often.
By the way, this is also a technique for guaranteeing semantics of
pointers to auto variables on machines with multiple register sets.
I mean, it doesn't *look* like an auto variable is being accessed
through a pointer, it probably isn't, and you'd like to put the auto
in a register for speed. But there is one teensy little indirection,
on an extremely infrequently used path, that you have to worry about...
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have nameserver
aglew@gswd-vms.gould.com - if you don't
aglew@gswd-vms.arpa - if you use DoD hosttable
aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.aglew@ccvaxa.UUCP (02/26/88)
..> Condition codes ..> Quick branch conditions: x<0, x=0, etc. Since this came up, I've been thinking that you can actually divide the conditions further than Katevenis did: Real Fast x < 0, x >= 0 -- single bit test Pretty Fast x == 0, x != 0, x == y, x != y -- requires unordered test of many bits Not So Fast x < y, etc. -- requires prioritized test of many bits Pretty fast could be converted into real fast by precomputing OR(all bits) for each register, eg.; doesn't add state because you don't need to save it. (Now if I just could figure out a way to store the overflow CC bit on a per register basis, without having to store it in memory)
oconnor@sunset.steinmetz (Dennis M. O'Connor) (03/01/88)
An article by aglew@ccvaxa.UUCP says:
] Since this came up, I've been thinking that you can actually divide the
] conditions further than Katevenis did:
]
] Real Fast
] x < 0, x >= 0 -- single bit test
Yes, and fairly common too.
] Pretty Fast
] x == 0, x != 0, x == y, x != y -- requires unordered test of many bits
Beg to differ. These are not neccessarily pretty fast. More below.
] Not So Fast
] x < y, etc. -- requires prioritized test of many bits
]
] Pretty fast could be converted into real fast by precomputing OR(all bits)
] for each register, eg.; doesn't add state because you don't need to save it.
Well, this last trick would help with X == 0 and X != 0, but not the
x==y or x!=y case. But what do you mean by "precompute" ? When
are you going tro do this ? If it's after register fetch, it's
not really "pre-", is it ?
But about pretty fast : Sorry, not really. It's only a LITTLE bit
faster than "Not so Fast" in CMOS : ever tried to make a 32-input
OR or AND gate go FAST in CMOS ? It's not much faster than the
carry chain, which has order-log2(word-size) gate delays.
] (Now if I just could figure out a way to store the overflow CC bit on
] a per register basis, without having to store it in memory)
Huh ? I missed this, what are you trying to do ?
--
Dennis O'Connor UUNET!steinmetz!sunset!oconnor
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)