On Feb 11, 2:37 pm, "Jason Burgon" <jayn...@[EMAIL PROTECTED]
> wrote:
> Yes, my mistake. The 6809 takes 1 cycle for an 8-bit data fetch or
store, 2
> cycles for a 16-bit one.
No wonder some C64 demos can do what they do! Dang. I had no idea I
was operating at such a disadvantage.
> > Throw me a bone here -- is there anything 8088 can do better (other
> > than DIV) than 6809? I'm asking seriously.
>
> How long does each loop of a rep stos[b|w] take on an 8088? The 6809
doesn't
> have any "machine gun" instructions (corrected a little later by
Hitachi's
> 6309), so it might be quicker at memory <-> memory copies.
REP STOSW on 8086 (the original) can set two bytes in a bus operation
(2 bytes in 4 cycles, for a net of 1 byte in 2 cycles), the 8088 is
hindered by the 8-bit BIU (bus interface unit) and can only set 1 byte
in 4 cycles. So although the 8088 is "machine gunning" as fast as the
bus will allow, there is still a 4-cycle limit per each byte of a
memory operation.
That being said, STOSW, MOVSW, etc. are 1-byte opcodes so it's still
worthwhile to use them (because they're small and because they update
offset/index registers for free) and in combination with REP you can
pretty much drive the machine as fast as it can go without anything
else getting in the way.
XLAT is also a godsend in tight loops.
> > ...I may have to do this:
>
> > type
> > noteIntervals=array[0..maxNotes*IBN] of word;
> > TPlayer = object
> > notesHz:noteIntervals;
>
> > That way the array type is defined outside of the object and the
> > compiler shouldn't complain.
>
> That's not such a bad idea anyway. I personally dislike the defining of
one
> type inside the definition of another.
Then I'm good.
Ok, I lied -- I was reading the OOP info in Chapter 9 of the manual
last night and now I have what is hopefully my last question: It's my
understanding that I can create an abstract object with boilerplate/
template methods (preferably filled with "runtime(211)" statements so
I can be sure my abstract is never called directly) and then create a
descendant with "real" methods. But the manual appears to illustrate
two ways of doing this, with and without the keyword VIRTUAL next to
my abstract methods in the original object. My question is: If I'm
going to overwrite most (or all) of the abstract methods with custom
code in every single descendant, would I even need VIRTUAL? Or is it
required to override a method?
|
