#Bruce Dawson Review
12 messages in this thread
Its true about straight line code being faster. One feature I find lacking in
allmost every assembler Ive used is a way to display clocks (or time) needed
for each line of instruction. Sure you don't need it all the time but when you
do it is a DRAG looking up every instruction.
Interestingly enough, JForth's disassembler shows clock cycles. Accepts
standard format (rather than the more common RPN assembler seen in Forth) and
disassembles in standard format.
Jon
Thanks for the tip. To bad MANX doesnt have such a utility.
Your suggestion about assemblers displaying clocks (or time) needed for each
line of instruction is unfortunately a meaningless request. NO assembler can
possibly take into consideration all of the variables which may affect the
execution time of each instruction. And if it _could_ it would be obsolete
before any copies could be shipped (some bright engineer would 'fix' some
problem and the results would now be wrong). I believe it would be an extreme
disservice to even _attempt_ to do this in an assembler (for one, the published
numbers would be _believed_). The ONLY way to find out how long a sequence of
instructions will take to execute, is to time the sequence of
instructions…..with a stopwatch. If you're in the business of needing to
know how long instructions take to execute and you have NOT yet written a
program to 'time' the execution of an arbitrary sequence, then I suggest that
you have an interesting project to work on now.
Thats wrong Im not interested in the time im interested in the number of CPU
clocks that are needed. I suppose you could figure out time by inputing the
cpu freq * clocks. That would be nice. Or I soppose you are talking about the
Time (again) difference when you take into account things like interrupts and
DMA. Again WRONG. I want to simply see the number of CPU cycles each
instruction takes. Sure I could look up each instruction in the motorola
manual but…. Isint that what computers are good for? However the idea you
have for a program is a neat one. How about this It would take a source file
and patch in jumps out to a timing check. Thus you could have a running count
of were the program is spending most of its time! That could come in handy for
tweeking a working program!
Jay,
The program you describe is a 'Profiler'… there is one on the Manx disk
and I think an updated version here in one of the libs.
– Keith
Ahh YES! Neat stuff! I like it. Still, I wish I had a clock counter.
Give me a BREAK….. I'm talking about intructions whose time (and cycles)
depend on the data (like multiplies and divides)….and on machines with
different speed memories on them. Regarding the program idea, I've written them
myself on two computer families already, since the documentation on the
machines is NEVER accurate, and every change to the machine (well almost every
one) will change the timing somewhere (or the number of clock cycles, or
whatever). I have not yet spent the effort on the Amiga as I don't yet have
any 'time critical' routines. The idea about jumping in an out is interesting,
but I think you will find that the Amiga clock is not well suited for this
task.
On instructions with variable execution times, the assembler would do the same
thing WE do: list a minimum/maximum time for the individual instruction, and
give a tallied minimum/maximum for the code segment in question.
As far as machines with (I assume you are referring to) different numbers of
wait states in memory, this is a constant WITHIN THE MACHINE IN QUESTION, and
can easily be bundled in after the fact.
What it comes down to is that there are times where certain loops and chunks of
code are very time critical. If you have serial data coming in at 475K Baud,
you know EXACTLY how much time you have to grab each byte, massage it, and
stuff it in the buffer before the next byte comes along. The loop doing this
job has to be worked out for maximum time and, if it exceeds this period, must
be recoded. There IS a need for machine cycle counts in many applications.
The simple fact that having an assembler (or other utility) which can do this
alleviates having to do it by hand.
Rick
I was hoping you would give me a break. But I guess not. Thats ok. But I
still don't agree that documentation on the machines is NEVER accurate etc.
But I will go along with you on the point about the amiga not being well suited
for that task. It is one of the reasons it is still the best machine around.
The fellow who did the hardware really rung out everything he could out of a
68000. And I really don't need the time critical stuff at this point. It just
seems like a nice option. And I have needed it for driver code that I written
on other machines. Hated looking up clock and timing it!! That really was my
point. A pie in the sky wish list.
I hate looking it up too, and every time I've tried it (haven't needed to with
the Amiga), I've been bitten badly by the docs. That's why I wrote the timing
programs for the other machines.
STRONGLY disagree. ANY assembler can calculate the EXACT number of clock
cycles required by any instruction. I do it by hand all the time and it
doesn't require any intelligence (why do I get the strange feeling I just
insulted myself?). The assembler has to index into a table to get an opcode
for a given instruction/addressing mode, it could just as easily pick up a
cycle count at the same point.
Your comments about "some bright engineer" fixing a problem don't apply at
all… we must be talking about two different things here, maybe?
Rick