1

I have this small little program written in assembly that squares a number.


Org 2010h
Db 0ah        

Org 2013h
Db 00h        

Org 1000h     
mvi a, 00h    
lxi hl, 2010h 

mov b, m
mov c, m      

CYCLE:
add b         
dcr c         
jnz CYCLE     

lxi hl, 2013h 
mov m, a       

hlt

I have a few questions regarding this program.

The first task is to determine the number of program memory cells necessary to store the program part in memory if each memory cell stores exactly a byte of information. The second task is to determine how many clock cycles are necessary to run the program.

What would be the logic here? How would I go about calculating these things? I don't understand this at all, any help would be appreciated. Cheers.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
franklin
  • 35
  • 7
  • 1
    Assembly language is the human readable version of what the processor interprets, which is called machine code. Machine code encodes everything as numbers, including instructions and operands. You need to determine the machine code encoding for this instruction sequence -- that will tell you how many bytes it takes to store the program part in memory. As far as clock cycles, you'll need a cycle reference cheat-sheet and then count it out -- this can be done from the assembly. The code has a do-while loop, whose loop body will execute 10 times. – Erik Eidt Dec 11 '19 at 22:50
  • 1
    @ErikEidt: http://pastraiser.com/cpu/i8085/i8085_opcodes.html has instruction size and cycle times for every 8085 instruction. @ OP: 8085 being non-pipelined makes perf analysis pretty trivial: each instruction has a fixed cost you can just add up, unlike modern CPUs where a loop isn't just a sum of its parts. – Peter Cordes Dec 11 '19 at 23:17
  • @PeterCordes @ ErikEidt thank you immensely. So, if I understand correctly, then looking at the very primitive program above, I can just use the link you've provided and just add up the values corresponding to each specific instruction? For example: lxi hl, 2010h ---- 3 bytes and 10 clock cycles. mov b, m --- 1 byte and 7 clock cycles. And the sum of the two would be just 4 bytes and 7 clock cycles ? Is it that straightforward or am I missing something? Cheers – franklin Dec 11 '19 at 23:35
  • 1
    Yes, for an older processor like this, it is that straight forward. – Erik Eidt Dec 11 '19 at 23:47
  • Thank you for taking the time, your responses have been very helpful. Regards. – franklin Dec 11 '19 at 23:54
  • `3 bytes and 10 clock cycles. mov b, m --- 1 byte and 7 clock cycles. And the sum of the two would be just 4 bytes and 7 clock cycles ?` - in traditional arithmetic 10 + 7 = 17, not 7. )) – tum_ Dec 12 '19 at 07:23

1 Answers1

4

https://pastraiser.com/cpu/i8085/i8085_opcodes.html has instruction size and cycle times for every 8085 instruction.

8085 being non-pipelined makes perf analysis pretty trivial: each instruction has a fixed cost you can just add up, unlike modern CPUs where a loop isn't just a sum of its parts.

For example, my answer on Finding the absolute value of a number in 8085 microprocessor assembly language includes a code-size / performance analysis.

or example: lxi hl, 2010h ---- 3 bytes and 10 clock cycles. mov b, m --- 1 byte and 7 clock cycles. And the sum of the two would be just 4 bytes and 7 clock cycles ? Is it that straightforward or am I missing something?

I assume you mean 17 clock cycles, but yes, it's that easy within a basic block (no branching).

8085 is so primitive it fully finishes executing one instruction before even fetching the next one.

Of course as Erik pointed out, you have to trace execution through the loop to get the dynamic instruction count/mix: the jnz is taken 9 times and not-taken once.

Code-size depends on static instruction mix (only counting each instruction once), but cycle time counts each instruction the number of times it's executed.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • Thank you for the detailed reply, on this post and my previous one. Feeling like a complete dumbass, but this is the learning process I guess :) Thank you for taking the time, this has really propelled me in the right direction. Regards. – franklin Dec 11 '19 at 23:53
  • 1
    @franklin: oh, I didn't notice that previous 8085 question was from the same person! heh. Yup, when something seems obvious in hindsight, it means you learned something :) (Or were having a brainfart. One of the two :P) – Peter Cordes Dec 11 '19 at 23:59
  • :) Just another follow up question: If I have a program that is a little bit more intricate and the clock cycle count could be in the thousands, how would I go about counting the clock cycles in that case? One of my assignments is to do exactly that, the program is fairly complex, so when counting the cycles manually I'm bound to make a mistake at some point. There must be an easier way, right? Regards – franklin Dec 12 '19 at 16:25