On Feb 11, 6:04 am, "Jason Burgon" <jayn...@[EMAIL PROTECTED]
> wrote:
> An 8088 takes much more than 4 cycles to load a register on average. A
6809
> takes between 2 and 8, but they are *real* numbers, not the
pie-in-the-sky
> numbers Intel used in their docs.
I (or Intel) never claimed that loading a register took 4 cycles; I
said that reading a byte (any byte) takes 4 cycles. As for the Intel
docs, the published numbers are correct; Michael Abrash proved it
using some special equipment if you don't want to believe me. He
writes about it in his Zen of Assembler book.
The reason people don't "believe" the numbers is because they are not
taking into account that the prefetch queue is only 4 bytes long, so
you need to account for the fact that instruction opcodes are also
going to need to be fetched -- and fetching each opcode byte is *also*
4 cycles as previously mentioned. So for example this:
MOV ac***,mem (10 cycles, 3 bytes)
....takes more than 10 cycles if it's not prefetched, it takes 10 +
(3*4)= 22 cycles.
> A 6809 also has 16-bit registers, and an 8
> * 8 MUL. A call ([L]BSR) takes 7 or 9 cycles, and a ret (RTS) takes 5.
Well, I've got a 16*16 MUL and a 32/16 DIV, so there ;-P But I agree
that the CALL and RET cycle times are pretty pathetic on 8088; even a
near indirect CALL is 16 cycles (so is near RET). And the IRET is 32,
which is why you can't drive any particular interrupt on a 4.77MHz
8088 any faster than about 15KHz regardless of what it does :-(
Anyway, the whole point of the challenge is how to make such a
"crappy" machine do something impressive, right? x86 is what I know,
and the original IBM PC is the 2nd-most difficult x86 platform to get
something done on, so I'm doing that for this particular challenge.
Throw me a bone here -- is there anything 8088 can do better (other
than DIV) than 6809? I'm asking seriously.
> > Okay, my last hurdle is something stupid that I can't find in the BP7
> > manuals: I have a field like this in my object:
>
> > TPlayer = object
> > notesHz[0..maxNotes*IBN] of word; {audible frequency of each note
> > plus all IBN intervals}
> > ...
>
> > ...where IBN is a const outside of the object. (It needs to be, since
> > the number of (I)ntervals (B)etween (N)otes is something that both the
> > song object needs, so it can validate effect input, and also the
> > player object, since it needs to set those intervals in Hz.) However,
> > the compiler is stopping on it with "Error 3: Unknown identifier.".
> > Why?? I can't add a const inside of an object, so does this mean
> > objects can't refer to constants?? I'm baffled by this.
>
> Me too, since this is perfectly legal *if* IBN is a true constant. The
> *only* answer I can think of is that IBN is not in scope when you define
> your TPlayer - it either hasn't been defined yet, or the unit it's
declared
> in is not in your "uses" statement.
Everything is in one program for now (I usually split stuff into units
as soon as the source gets unwieldy) so it's definitely in scope. I
think that, to get around it, instead of this:
TPlayer = object
notesHz[0..maxNotes*IBN] of word;
....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.
Thanks for your help!


|