assembler code fails to run correctly on chip
magnet
Posts: 13
I have run my assemble code fine with many sets of data all with success in the simulator, yet when loaded into the propeller chip in ram or to the eeprom it fails to run correctly and never finds the correct result, thus the code never finishes. Any pointers what my next course of action should be to find where the problem is please?
Just for anyone else fearing the jump to using assembler... the speed up is amazing!
regards
magnet
Just for anyone else fearing the jump to using assembler... the speed up is amazing!
regards
magnet
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
The program runs 100% correctly within this simulator no matter what starting values I give it in the supplied data that I am using to test my code so code integrity would seem to be ok.
I think the simulator is robust enough to handle a simple addition and subtraction program with no major trick programming techniques being used in it without being so buggy.
The only thing I can think of is the indentation of the assembler code and that the simulator might be more tolerant of this, but I'm not sure this is the case with assembler, although critical in spin code.
Consider these 2 pieces of code...
<label> mov a,b wc
and this one
if_c mov a,b wc
Does the "if_c" have to be indented even if it does not have a label in front of it?
This is the only thing I can think of so far is the formatting of my code, despite the fact it compiles without errors and runs fine in the simulator.
Comments welcome.
magnet
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
- The indentation does not play a role, none.
- Instructions and conditions are parsed before labels, that means that if a "label" hapen to have the same name as an instruction, it is going to be treated as an instruction, regardless of it is indented or not.
So;
And
And
produce the same code, and the same address for the label
Something you may want to have in account is the terminating code, at the end of your program what do you do ?, a jum to itself ?, a cogstop ?... or you just leave it open ? When coginit is executed 496 longs are copied into COG's RAM, so anything after your program will be treated as instructions.
A sample of a non-working code may help us (me to uncover a bug maybe) to find the problem.
Ale
Broken propeller chip!
Changed the chip and the code works! I have no idea how the chip got broke though?!?
Regards
magnet (highly embarrassed mode engaged)
JT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
The old chip has that smell of being fried and could be due to the plug adaptor I was using failing on me last week. When tested it shows a massive current that then fades down to a trickle. I think it did my prop chip no favours. Anyhoo, new chip in circuit and new power supply now. Old spin code examples all working so the hardware seems to be fixed. I've been using some really old code from my Amiga days to try and learn programming on this chip so forgive the complete pointlessness of the code, but the simple gist of it is to add a number to a running total and if the result is higher than the target then to subtract another number and repeat until the 2 values are equal. There are not many loops in the code and the leds flash a bit too fast so maybe should try changing the starting values to some bigger range. If the code finishes its run and the 2 results do not match then it should go into an infinite loop and keep the red led I have on pin 20 alight, which it does. The loop counting led on pin 15 does flash once per outer loop fine. If the 2 results match then it should jump to the other led routine that lights a green led on pin 18.
Really hope someone can spot the novice mistake I have made or offer an explanation why it still doesn't work.
Has anyone else tried running it in the pPropellerSim without any errors?
I'm still getting these 2 results every time I've tried. Simulator fine, chip fails.
Regards
magnet
it was difficult for me to restrain from "optimizing" your code - but I succeded
I think the issue is here:
subs r03,temp wc if_c add r03,v1000You seem to assume that C is set when SUBS results in a negative value. That is not the case however. It seems that the author of the simulation program erred likewise
The meaning of C within ADDS and SUBS has been carefully chosen to allow easy multiprecision arithmetic with ADDX, SUBX
Post Edited (deSilva) : 1/10/2008 7:47:21 PM GMT
subs r01,temp
cmps r01,#0 wc
if_c add r01,v1000
and it still fails, so although I made a mistake, this alteration has not made the code run correctly. (Simulator still works fine! Grrr)
I tried the code on some small numbers and it ran ok, but it still fails on larger numbers, so something still isn't right.
Regards
magnet
Post Edited (magnet) : 1/11/2008 3:21:42 AM GMT
cmps a, b wz,wc if_b jmp #less_than if_e jmp #equal if_a jmp #greater_thanThe condition tests "if_b", "if_be", "if_e", "if_ae", "if_a", "if_ne" meaning "below", "below-or-equal", "equal", "above-or-equal", "above". The same conditions work with cmp for unsigned comparisons. It saves having to remember the meaning of Z and C after a comparison (although its not that difficult, C is set for less-than, Z for equal)Note that comparisons never "overflow" or "underflow" since they don't alter the operands. add and sub can overflow and underflow and in different ways for unsigned and signed values.