assembler/debugger

Sorry for repeating the question in the other post.. but i think the topic title could have been misleading. thank u all for the answer i had.. still one point missing. I would like to practice assembly not in basic inline. i ve risc os on BBxm. which assembler should i use? Is there a step by step debugger? I fount extasm and armaliser/reporter.. are these correct choices? Thank u al very much.

I’m not an assembler guy, but I found this site:

http://www.heyrick.co.uk/assembler/

Seems quite helpful. I don’t know anything about the tools you mention, but you could also have a look at GCC, it’s obviously a heavyweight set of tools, which may or may not be to your liking.

Cheers

Garry

First and foremost, why do you insist on not using BASIC’s inline assembler? It’s very much the simplest and easiest option, doesn’t require you to download any additional software at all, and I’d have thought would be by far the most suitable for a complete beginner such as yourself.

For an ‘official’ solution, you can buy the C tools from the ROOL store (at least theoretically; they seem to be being a bit unhelpful at the moment, but I’m sure Steve will sort it out if you ask him by email), but it’ll set you back a hefty £40.

For a free solution, GCC has been ported, but I believe the latest stable version is incompatible with the BeagleBoard and the unstable version is, erm, very unstable and largely incomplete, and I think you have to build it from source (which is a fat lot of good when you don’t already have a working compiler). (Also, beware of riscos.info – it’s one of many unmaintained RISC OS documentation websites which contains an awful lot of outdated material, so try not to click on any links.)

The ROOL Tools have been updated to work on the BeagleBoard, and the assembler now has full support for ARMv7 instructions, but if you only want the assembler I’d still recommend BASIC. The BASIC on your computer can only assemble the original ARM instruction set, which will probably be enough for you, but if you want ARMv7 instructions in BASIC you should check out TBA Software’s project.

For a free, sane, updated, and working solution, there is of course extASM, which you said you’d found. This has support for ARMv7 instructions and works on the BeagleBoard, but I’ve never used it so can’t give you advice. It may well be the best solution for you.

Is there a step by step debugger? No. Absolutely not. Sorry. There were some, but I think all of them were abandoned before they could be updated to work on the BeagleBoard. (extASM may have one, but I don’t think it does.)

ARMalyser and Reporter are useful tools, but one is a reverse engineering tool and the other is intended for BASIC and isn’t really suitable for assembler. I’m not sure what you were planning to do with them.

Just as an example, in case you were afraid of BASIC, here’s how you can use it to assemble a program:

(Disclaimer: untested!)

codesize%=128:REM enough for a 128 byte program (way more than we need)
DIM code% codesize%-1:REM allocate memory to assemble into
FOR pass%=8 TO 10 STEP 2:REM two-pass assembly (to make labels work)
P%=code%:L%=code%+codesize%:REM safeguard to make sure we don't overflow memory
[OPT pass%
ADR R0,string%
SWI "OS_Write0"
SWI "OS_Exit"
.string%
EQUS "Hello world!"
EQUB 0
ALIGN
]:REM close square bracket denotes end of assembly
NEXT
REM you'll probably want to change this filename
SYS "OS_File",10,"SCSI::4.$.HelloWorld",&FF8,,code%,P%

Thank u very much. The reason I don’t want to use Basic is that I ve no really need to develope an application.
I only want to learn “low level” thing. What I really love is:
Writing a code at low level, assemble it and watching it working step by step. So I’ll see exaclty where and how is loaded into memory.. how interacts with the os…
For example: what exatly happens when I load a program in in risc os?
Just to sum it up I would like to see how everything works just watching carefully to every little step id does (and studying from books..).
Thank u for ur suggestions seems like if I wont be able to assembly with extasm, I ll fallback to Basic.

For a free solution, GCC has been ported, but I believe the latest stable version is incompatible with the BeagleBoard

4.1.1 release 2 should work fine. However I think the assembler only supports up to ARMv6; for ARMv7 you’d have to build GCC 4.6 from source.

the unstable version is, erm, very unstable and largely incomplete, and I think you have to build it from source

I’m not sure how stable it is nowadays, but you’re certainly right about having to build it from source.

(which is a fat lot of good when you don’t already have a working compiler)

It’s impossible to be built on RISC OS. You just build it on a Linux (or similar) PC instead. If everything works properly it should spit out a native RISC OS version of the compiler.

Is there a step by step debugger? No. Absolutely not. Sorry. There were some, but I think all of them were abandoned before they could be updated to work on the BeagleBoard. (extASM may have one, but I don’t think it does.)

extASM doesn’t have a debugger. The only single-step debugger I know of that’s still being maintained is DDT, but that doesn’t run on the BeagleBoard yet, so there’s not much point looking at that.

Unfortunately I don’t think there are any accurate and up-to-date tutorials on how to get started writing ARM assembler for RISC OS. I think the best sources of information are:

• Heyrick’s site – For a good introduction to ARM assembler
• Castle’s site – For the issues faced when dealing with 32bit code
• This guide on the ROOL wiki on ARMv6/ARMv7 compatability

It’s important to know the difference between 26bit and 32bit code, otherwise there’s a good chance anything you write won’t run at all on the BeagleBoard. As a brief introduction:

• The first few generations of ARM processor ran in “26bit mode”. In this mode, register R15 stored two bits of information – the program counter (aka PC), which indicates the current address being executed, and the processor status register (PSR), which controls whether interrupts are currently enabled/disabled, stores the ALU flags that are updated by comparison instructions, etc. Storing both of these in the same register made it very easy to preserve the PSR flags when calling subroutines or SWIs.
• However the big downside to the 26bit mode was that it limited the processor to only being able to execute code from the lower 64MB of RAM. So in 1993/1994 ARM introduced the “32bit mode”, where the PSR was moved out of R15 and into a new register, complete with new instructions to read & write from it. The fact that a new register has been introduced means that function calls made in 32bit mode will no longer automatically preserve the PSR flags, which will cause any code relying on that behaviour to break.
• To ease the transition period, for a while there were processors available which could switch between 26bit and 32bit mode at runtime. Acorn used these in their RiscPC-era products, since RISC OS 3 wasn’t ready to make the switch to 32bit mode. It wasn’t until Castle released the Iyonix that a 32bit compatible version of RISC OS was publicly available.
• But what this means for you is that you need to watch out for things like the following in any example code you see. They’re all things which are likely to be written to run on 26bit CPUs, and may not work correctly (or at all) on new 32bit-only ones.
  • MOVS PC,LR
    • ALU instruction (MOV, ADD, SUB, ORR, etc.) with the ‘S’ suffix and the PC as the destination
  • LDMFD R13!,{ … some registers here … , PC}^
    • LDM of PC with ‘^’
  • TEQP …
    • ‘P’ suffix on comparison instruction

ARMalyser and Reporter are useful tools, but one is a reverse engineering tool and the other is intended for BASIC and isn’t really suitable for assembler.

I think Martin would not be pleased to hear that Reporter is only intended for BASIC; I use it all the time in assembler, and very handy it is too.

I do endorse your recommendation of the BASIC assembler, but I am aware that it might be a bit short for the new boards. I would recommend Darren Salt’s Extended BASIC Assembler, but you have to use it with version 1.20 and it is unlikely to be updated, I fear.

The way I’ve usually been debugging (the extASM source itself is 21,000 lines of ARM assembly code) is the good old “print” method: Define a bunch of macros that lets you print out various things (and not disturb the registers). I have macros like this:

MOV   R0,#123
MOV   R1,#456
ADD   R2,R0,R1
Print3 "Add numbers, R0, R1, R2=",R0,R1,R2:NL

When run, this will print:

“Add numbers, R0, R1, R2=123 456 579” (newline)

There’s also a “Get” macro, which does an OS_ReadC, i.e. pauses until you press a key.

This has proved sufficient for all my debugging needs, and in fact even for higher-level languages I tend to prefer the “print” method to single-stepping in a debugger.

To start with, I’d also recommend using the BASIC assembler, though, and you can develop similar “macros” for debugging, or for extending the instruction set, there:

DEF FNnl
[OPT pass%
SWI   OS_NewLine
]
=""

... (ARM instructions)
FNnl
...

ARMalyser and Reporter are useful tools, but one is a reverse engineering tool and the other is intended for BASIC and isn’t really suitable for assembler.

Strange, then, that I use Reporter extensively for debugging assembler (all written using the BASIC assembler). This includes several modules (eg ArmSort), and even Reporter itself!

Macros are provided for use of Reporter from the BASIC assembler. Debug output is in a scrollable window, updated every WimpPoll.

Is EasyGCC something worth revisiting some time?

Thank u very much to u all for the support.
I noticed someone gave me hint to write debuggable sw.
Just a note, I don’t really need to write code. I just need to be able to understand how machine work.
Nowadays, people in IT, solve a problem just trying to found the solution.
For example, people just try to connect a pc on lan, connectin the cable. If it doesn’t work disconnect and reconnect. Even “technicians” sometimes doesn’t know how exactly IP works, what is ISO OSI, DNS and more..
I don’t really need to do anything. Just want DEEPER knowledge. But to learn u have to practice too, and then I came here to find help about best practices, and u gave me lot of interesting suggestions. Thank u.

“for ARMv7 you’d have to build GCC 4.6 from source.”
kind of a bummer.. I was hoping just to download it.

For a ARM Debugger:-
!DeskDebug – good info on ARM game enclosed with demo.
!DDT patched for Beagle.
QDD by Adrian Lees – not tried with Beagle.
Could use !Arm_Debug – up to RO4 – with !ArcEm
for testing bits of code.

Hi, I wanted to try deskdebug, but the download doesn’t work… I asked them, and I m waiting since a couple of weeks..
There is a way to try DDT before buying it?
I don’t know QDD… I ll search for it.
Just a couple of STUPID questions:
- Debugging step by step, could be obtained just setting a breakpoint on the next address and after remove it and setting again? (a sort of “manual” step by step?)
- Seems to me that in the Risc os source code (like in other oses sources as well) there are few comments. When I write code, I usually write a lots of comments and info about what that piece of code does and how. Why this is not a common practice? (correct me if I m wrong)
Thank u very much.

Just to put my oar in, I use Reporter to debug from BASIC, assembler and C code. It’s great! :)