Assembler debugging advice

@ Fred

I think this is the rare crash that I get which I belive is different to the crashes I was getting that seemed to be connected with commented out code!!

The only thing that uses “PlotSprite_C” is “Plot_Aliens”. I have been all over “PlotSprite_C” and can’t figure it out. I suspect that the problem, if it does lie here in “PlotSprite_C”, is to do with the clipping or something somwhere has corrupted X,Y position of alien causing the issue since the address to plot alien at is like you said not word aligned.

Looking at the offset into the screen, &BA ( 186 pixels ) this would put it 2 thirds across the screen at the top and would imply if it is the clipping at fault the it would be the Y clipping. I’ll have another look.

@ Martin

Can’t remember who I asked for help but it turned out all I had to do was repeatedly press ESCAPE until I got desktop back and then remove Reporter and re-boot. Took 2 days to get this answer. It was a nightmare with no computer :-)

nightmare

Not sure what was wrong there. The latest version has improved both the way it works, and the instructions. It will not cause problems if !Reporter is moved or deleted. It can even be disabled by pressing a key during boot (if your keyboard is active). But reading the instructions is important, as fiddling with !Boot can cause nightmares.

And for simple program debugging, there is no need to start Reporter at boot time anyway!

I noticed that you had given data addresses labels, but you did not use these in the code, falling back on numeric offsets.

This is it.

This is exactly it.

The countdown timer (guess) was a red herring, but upon seeing Steve’s observation I tried something…

The omitted countdown code was eleven instructions. So I inserted eleven MOV R0, R0 (NOP) instructions.

And your program promptly blew up when the ship was crashed into, but unfortunately it doesn’t seem to be generating an abort so *ShowRegs gives no indications.

That said – the fact that your program seems to misbehave when instructions are added to it implies something really weird is going on (with memory offsets?). You’ll want to look into that first as otherwise it could lead to problems adding features/code further down the line.

• I am working with the objasm build as it is easier for me that way. To trigger the same behaviour in the BASIC code, insert 64 NOPs in place of the countdown bit mentioned above (or just insert ‘em there anyway?). That will cause the game to bomb at the ship explosion. The difference in NOP count is because the DDE-built program has an APCS style header, and there are a few instructions to set up the stack (as we’re not running in BASIC so can’t rely upon R13 being anything useful on entry).

but upon seeing Steve’s observation I tried something…

Observation based on mucking about hacking old 26 bit modules into 32 bit versions. Get the alignment wrong and things just go pop either on start up or at a ‘random’ point in use. Not random obviously, it’s when the unaligned code element gets used.
Sometimes just adding the extra items in the header for 32 bit use does the breaking work.

@ Martin

Have you got the link for latest version of !Reporter. I think I should start to take a look at it again

@ Rick

This does sound very likely. Got a long day at work tomorrow so take a look on Tuesday to see what I can spot :-)

This is exactly what is happening

@ Steve

Sometimes random observations are the most significant, it just takes somebody to recognize it. So thanks for thinking out loud :-)

TIA to you all

link for latest version of !Reporter.

http://www.avisoft.f9.co.uk and also available on !Store.

the Reporter library version is much more flexible.

Yes, it is, but I wrote my routine a very long time ago, perhaps before there was a Reporter library. It has served me well ever since. I could not write assembler without it. ;-)

Can somebody explain to me when you return from a BL is the next instruction to execute at R14. Im unsure how the pipeline works with scheduling instructions

Can somebody explain to me when you return from a BL is the next instruction to execute at R14.

When a BL is executed, the processor stores the “return address” in R14. When you have returned from a BL, the old return address is still there as nothing automatically overwrites it.

Im unsure how the pipeline works with scheduling instructions

It depends upon the ARM family and “it’s complicated”. Old ARMs executed instructions and throws them away on a branch. Modern ARM may have multiple execution and prediction and out of order execution…

Hi there Rick

The reason why I’m asking is because I’m still trying to track down this bug and my code isnt always ( hardly ever ) giving me any chance to *showregs – until now.

I have identified the crashed instruction and doesnt seem to make any sense as it has crashed in a routine which has not been called anywhere in my code ( obviously something is wrong ) so I thought I would go back to the point where this piece of code was called from. BUT. When I look at the instruction stored at the address in R14 there is a BL instruction and at the address before but there is also another BL before these 2. Now not sure how pipeline works and I dont want to go chasing dead ends which BL should I be looking at ?

Ignore my previous post. I’m getting myself confused :-)

One thing I will say is that – as far as an application programmer is concerned – the internal structure of the pipeline (and how it differs from one CPU to another) is irrelevant. Instructions always execute in “program order”, i.e. the same order that they’re listed in the program source. If you’re familiar with MIPS then there aren’t any branch delay slots or anything else like that to worry about. The last change that was made to the pipeline that could affect the execution of application code was about 20 years ago, where STM xx,{…PC} and STR PC,[xx] were changed so that they would store PC+8 instead of PC+12 (to match MOV xx,PC). (Yes I know the 26bit to 32bit change had a major impact on applications as well, but that change was mostly to do with register allocation, not the pipeline :-))

If you’re writing hardware drivers or multithreaded code then things get a bit more complicated (e.g. barriers might be needed to ensure memory accesses occur in the right order), but for an ordinary single-threaded application everything is guaranteed to occur in “program order”.

The only other time you might want to worry about the pipeline structure is when you’re trying to optimise code, e.g. to take advantage of dual-issue on superscalar CPUs. There are a few basic rules you can follow to help with this (e.g. avoid read-after-write dependencies between adjacent instructions), but that’s really a topic for another thread :-)

the internal structure of the pipeline (and how it differs from one CPU to another) is irrelevant.

That’s why I said “it’s complicated”. :-)

The reason why I’m asking is because I’m still trying to track down this bug and my code isnt always ( hardly ever ) giving me any chance to *showregs – until now.

Yes, it is disappointing that DDT failed, but I notice that objasm stalls for a long time making your game – I’m guessing the BASIC way of writing things is rather different to the DDE way (that would like things in neat and tidy AREAs).

I have identified the crashed instruction and doesnt seem to make any sense as it has crashed in a routine which has not been called anywhere in my code

I’m not sure that it is a valid assumption.

On my copy (BASIC or DDE builds), inserting a few NOPs caused the game to abort when the ship blew up. This should not
happen. No, I don’t mean as a bug – it’s obviously misbehaving! ;-) I mean, inserting some instructions should not cause the program to behave differently.

Therefore:

BUT. When I look at the instruction stored at the address in R14 there is a BL instruction and at the address before but there is also another BL before these 2.

…I have a feeling that you are looking at a symptom of the problem, rather than the problem itself. In my case, that the ship crashing works without the instructions, and it works again if I insert 64K of NULL bytes (and jump over it), indicates to me that the ship crash code is working. Something else is affecting it.

The hard work for you, now, is to look at your memory accesses (yes, all of them) and verify two things:

• Is the memory location being accessed the correct one?
• Is there an easier, clearer, way to do this?

I appreciate that you are using R11 as a base for the working data, but it leads to code like this which frightens me:

   LDRLT  R4,[R11,#1412]
   LDREQ  R4,[R11,#1416]
   LDRGT  R4,[R11,#1420]

This works, as it is the quit/die/complete message – but being hardwired to these locations means that the data structure cannot ever change without involving potentially many rewrites. Would it not be simpler to place the messages closer to where they are needed and then just ADRLT/ADREQ/ADRGT directly to them?

A few screenfuls down, we’re reading from R11+860, with no comment. Then we’re loading R9 from R11+868 and writing to R9+544.

That the game (mostly) works shows that most of this works. But that problems are cropping up indicates that something…isn’t working. I know, DUH. But given the “moving goalpost” issue, I would look at errant memory access as being a potential problem and what we’re seeing being a symptom.

Ive dabbled for a number of years and coded some simple bits and pieces but still consider myself someone still on a learning curve for many things you yourself would consider straight forward but what you have just said above makes a huge amount of sense and i appreciate it. You have an excellent understanding of my problem so respect to you for the time you have given. Thank you.