Reasonable expectation for # of opcodes for arithmetic?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Reasonable expectation for # of opcodes for arithmetic?

JavaJack
The book didn't attempt to set my expectations for the typical number of assembly opcodes that the code generator should emit for, say, the "add" operation (I started with this one first since it's used by the "SimpleAdd.vm" program).

I started with around 10 lines of assembly and got it down to 8, and I'm probably overthinking things, but I don't have a sense as to whether I'm "doing it right". What's typical?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

cadet1620
Administrator
JavaJack wrote
The book didn't attempt to set my expectations for the typical number of assembly opcodes that the code generator should emit for, say, the "add" operation (I started with this one first since it's used by the "SimpleAdd.vm" program).

I started with around 10 lines of assembly and got it down to 8, and I'm probably overthinking things, but I don't have a sense as to whether I'm "doing it right". What's typical?
8 is reasonable, although it can be done in fewer.  I don't remember what I started out with, but I do know that I had additional insights as I was working on other code generation and was able to go back and tighten up the code.

--Mark
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

Dano
In reply to this post by JavaJack
10 is fine. Remember, premature optimization is root of all evil. You can always return to the code later when it is needed.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

JavaJack
Yeah. Still, it would be nice if the text did give rough estimates so you'd know if you were at least in the right zipcode.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

Albert G
Time to brag: I got the add (actually all binary arithmetic ops down to 5 opcodes. Here is a summary of what I get:

binary ops (add,sub,and,or): 5 opcodes
unary ops (not, neg): 3 opcodes
logic (eq,lt,gt): 10 opcodes

As for the push/pop primitives:

push indirect (local,argument,this,that) : 9 opcodes
push direct (pointer/temp/static) : 6 opcodes
push constant: 6 opcodes

pop indirect (local,argument,this,that) : 13 opcodes (this one needs an intermediate register - R13)
pop direct (pointer/temp/static) : 6 opcodes

Albert

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

krakerjak
add, and, or = 6
sub = 9
not, neg = 3
eq, lt, gt = 15
push constant = 6

The rest I have yet to implement.
I don't plan to look into making any of these more optimized until I have my translator 100% implemented and working. I know I can shave a few off some of them.

Im curious about sub as you'd think the only difference would be a '-' vs a '+' comparing to the add routine but the sub routine won't do 2's complement subtraction with the subtraction opcode.

Maybe thats a error relating back to my hardare implementation back in my earlier chapters.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

cadet1620
Administrator
krakerjak wrote
Im curious about sub as you'd think the only difference would be a '-' vs a '+' comparing to the add routine but the sub routine won't do 2's complement subtraction with the subtraction opcode.

Maybe thats a error relating back to my hardare implementation back in my earlier chapters.
Subtraction C-command does do 2's compliment subtraction. You might have an order dependency, though, since x-y != y-x.

Any errors in your hardware implementation won't effect the CPU Emulator.

--Mark
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

krakerjak
hmm, ill have to look into this when I get home tonight.
i think you're right. i mistakenly did y-x instead of x-y
I wasn't able to pass the stacktest.vm program when I translated it with my translator. And troubleshooting led me to the 'sub' vm instruction.

There is a section in the stacktest sample program where you have:
push constant 31
push constant 53
add
push constant 112
sub

You can see that you have...
31+53 = 84
then
84-112 = -28
in the cpu emulator I got +28 causing script comparison to fail.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

krakerjak
yep, i did do y+x and y-x in both add and sub vm commands.
that fixed it
Thanks cadet
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reasonable expectation for # of opcodes for arithmetic?

sankar.lp.gym
This post was updated on .
In reply to this post by JavaJack
Maintainability is more important than optimization


[advertising link deleted. --admin]
Loading...