Small IRA Tutorial

[hooverphonique]

Originally Posted by phx

Looking at the list of modifications I probably wanted to finish

HUNK_RELRELOC32

support. But this hunk is very rare. I wouldn't be surprised if vasm is the only assembler which can create it.

But vasm is what all the cool kids use these days

[hop]

Originally Posted by phx

Will upload to Aminet tomorrow (if I don't forget it).

That would be great thanks.

[phx]

In the final testing this afternoon I ran into a 020 disassembler bug, which should better be fixed. Give me one or two more days.

[Karlos]

Every time I see this thread title, I imagine a red flag being raised somewhere in MI5

[hop]

Originally Posted by phx

In the final testing this afternoon I ran into a 020 disassembler bug, which should better be fixed. Give me one or two more days.

That's great.

I don't want to derail the imminent release, but for a future release, would it be possible to consider offering an option to construct label names from addresses rather than indices?

I'm not very familiar with the code, but something like

    if (addressLabels)
        if (addr > 0xffff)
            fprintf(ira->files.targetFile, "LAB_%08lX:\n", (unsigned long) adr);
        else
            fprintf(ira->files.targetFile, "LAB_%04lX:\n", (unsigned long) adr);
    else
        fprintf(ira->files.targetFile, "LAB_%04lX:\n", (unsigned long) index);

For example instead of:

LAB_007E:
	ADDQ.L	#4,D1			;1a42: 5881
	ADD.L	D1,4(A7)		;1a44: d3af0004
	SUB.L	D1,(A7)			;1a48: 9397
	LEA	EXT_000c,A1		;1a4a: 43f900007700
	MOVEA.L	LAB_007A.W,A2		;1a50: 24781a08
	TST.B	9(A2)			;1a54: 4a2a0009
	BNE.S	LAB_007F		;1a58: 6628
	CMPI.B	#$02,10(A2)		;1a5a: 0c2a0002000a
	BCC.S	LAB_007F		;1a60: 6420
	MOVEQ	#0,D0			;1a62: 7000
	MOVE.B	8(A2),D0		;1a64: 102a0008
	SUBQ.W	#1,D0			;1a68: 5340
	MOVE.W	D0,LAB_0080		;1a6a: 33c000001a88
	MOVEM.W	(A2),D6-D7		;1a70: 4c9200c0
	MOVE.B	10(A2),D5		;1a74: 1a2a000a
	ASR.W	#4,D6			;1a78: e846
	ADD.W	D6,D6			;1a7a: dc46
	SUBQ.W	#1,D7			;1a7c: 5347
	BSR.W	LAB_0081		;1a7e: 6100000a
LAB_007F:
	MOVEM.L	(A7)+,D0/A0		;1a82: 4cdf0101
	RTS				;1a86: 4e75
LAB_0080:
	DS.W	1			;1a88

we could have:

LAB_1a42:
	ADDQ.L	#4,D1			;1a42: 5881
	ADD.L	D1,4(A7)		;1a44: d3af0004
	SUB.L	D1,(A7)			;1a48: 9397
	LEA	EXT_000c,A1		;1a4a: 43f900007700
	MOVEA.L	LAB_1a08.W,A2		;1a50: 24781a08
	TST.B	9(A2)			;1a54: 4a2a0009
	BNE.S	LAB_1a82		;1a58: 6628
	CMPI.B	#$02,10(A2)		;1a5a: 0c2a0002000a
	BCC.S	LAB_1a82		;1a60: 6420
	MOVEQ	#0,D0			;1a62: 7000
	MOVE.B	8(A2),D0		;1a64: 102a0008
	SUBQ.W	#1,D0			;1a68: 5340
	MOVE.W	D0,LAB_1a88		;1a6a: 33c000001a88
	MOVEM.W	(A2),D6-D7		;1a70: 4c9200c0
	MOVE.B	10(A2),D5		;1a74: 1a2a000a
	ASR.W	#4,D6			;1a78: e846
	ADD.W	D6,D6			;1a7a: dc46
	SUBQ.W	#1,D7			;1a7c: 5347
	BSR.W	LAB_1a8a		;1a7e: 6100000a
LAB_1a82:
	MOVEM.L	(A7)+,D0/A0		;1a82: 4cdf0101
	RTS				;1a86: 4e75
LAB_1a88:
	DS.W	1			;1a88

This would offer a couple of advantages:

1. The user can see branch destinations and data addresses a glance

2. When new code is discovered and entered into the config file, the changes (diffs) to the regenerated disassembly would be minimised (good for comprehension and subsequent modification)

An obvious disadvantage is that label names would be longer, so it might be sensible to put this naming mode behind a command line option.

[jotd]

I have post-processing scripts that do exactly that and it's super-useful for all the reasons quoted.

Plus when I discover jump tables & automatically insert entrypoints it's straightforward.

[phx]

V2.10 is released: http://aminet.net/dev/asm/ira.lha
But I didn't include the fix mentioned above, as it became too complex and I didn't want to break the release now.

The "bug" is also not too bad: it just doesn't reassemble instructions with PC-relative addressing mode at the moment, when the destination is outside of the current section. I would prefer to display a numeric PC-displacement instead of a label in this case, and additionally make it work with RELRELOC32 hunks when labels from a different section are referenced.

Originally Posted by hop

I don't want to derail the imminent release, but for a future release, would it be possible to consider offering an option to construct label names from addresses rather than indices?

Yes, that could be a nice enhancement. I'm looking into it for V2.11. But via an option as you wrote.

[hop]

Originally Posted by phx

V2.10 is released: http://aminet.net/dev/asm/ira.lha

Thanks. Would it be possible to add a Windows ira.exe to the archive, like the last release?

Originally Posted by phx

Yes, that could be a nice enhancement. I'm looking into it for V2.11. But via an option as you wrote.

Fantastic. I'll look forward to this.

[hop]

Originally Posted by jotd

I have post-processing scripts that do exactly that and it's super-useful for all the reasons quoted.

Great. Could you please point me at it? Is it one of the ones in https://github.com/jotd666/amiga68ktools ?

[hop]

Originally Posted by phx

Yes, that could be a nice enhancement. I'm looking into it for V2.11. But via an option as you wrote.

I've made this change locally, and it seems to work great. I've attached an archive containing the changes.

-LABADDR          Label names constructed from address

The archive also contains a Windows ira.exe. I added instructions to build using Makefile for Windows to the readme, and a CMakeLists.txt, which allows the executable to be easily built and debugged from within Visual Studio.

EDIT: Non-Windows binaries in the package have not been rebuilt.

[phx]

Originally Posted by hop

I've made this change locally, and it seems to work great.

Very nice! And sorry that I didn't reply earlier, because I already implemented these changes 5 days ago. The current V2.11 beta source is here:
http://sun.hasenbraten.de/~frank/TEST/ira_211_beta.lha

I added this new option:

        -LABEL=<style>    Label style 0=LAB_index, 1=LAB_addr.

The default is still the old label-style 0.

[zenox98]

@phx
bad d/l link ?

[hop]

Originally Posted by phx

Very nice! And sorry that I didn't reply earlier, because I already implemented these changes 5 days ago. The current V2.11 beta source is here:
http://sun.hasenbraten.de/~frank/TEST/ira_211_beta.lha

I added this new option:

        -LABEL=<style>    Label style 0=LAB_index, 1=LAB_addr.

The default is still the old label-style 0.

Haha. Thanks for this - it's a worthwhile feature. At least you can take my warning fixes. EDIT: And possibly the CMakeLists, if it can be fixed up for other platforms.

The link is broken for me too.

[hop]

@phx It might be worth adding a line in ira_config.doc to inform the user that lines starting with a ; are treated as comments.

[jotd]

nice update, buit link is indeed dead

[phx]

Indeed, the last underscore in the URL must be removed. Sorry. Correct would be: http://sun.hasenbraten.de/~frank/TEST/ira_211beta.lha

Originally Posted by hop

At least you can take my warning fixes.

Which warnings? Can you provide a diff for those?

And possibly the CMakeLists, if it can be fixed up for other platforms.

Is it for Visual Studio only? I have no experience with CMake. Not sure if I would be able to update the list in future.

[hop]

Originally Posted by phx

Which warnings? Can you provide a diff for those?

They are simply removing a bunch of warnings of the form:

T var = var;

I queried this unfamiliar pattern on another thread sorry.

The changes should be in the archive I posted a few posts up in this thread. Is there a standard way to distribute diffs other than modifed files?

Originally Posted by phx

Is it for Visual Studio only? I have no experience with CMake. Not sure if I would be able to update the list in future.

Updating the list of files is easy.

I have only tested this CMakeLists.txt to generate Visual Studio project files and build with Visual Studio. It should be straightforward to adapt to other platforms for anyone with experience. The only thing that might have to be done is to add the compiler options for other platforms/toolchains from the Makefile(s).

I'm not familiar with CMake on OSX or Amiga OS, but something like

# Compiler-specific options
if(MSVC)
	target_compile_options(
		${IRA_TARGET} 
		PRIVATE
#		/W4  # ideally!
		/wd4996 # Disable warning regarding deprecated functions "use strcpy_s instead of strcpy" etc
	)
else if(CMAKE_C_COMPILER_ID STREQUAL "GNU")
	target_compile_options(
		${IRA_TARGET} 
		PRIVATE 
		-m32
	)
else if(CMAKE_C_COMPILER_ID STREQUAL "VC")
	target_compile_options(
		${IRA_TARGET} 
		PRIVATE 
		-dontwarn=214
		-DAMIGAOS
		-D__USE_INLINE__
	)
endif()

Perhaps there is someone with experience who could test, if this is required.

[phx]

Originally Posted by hop

T var = var;

I queried this unfamiliar pattern on another thread sorry.

Oh, I see! Looks like nonsense. Removed the

= var

in all cases now. Thanks!

Is there a standard way to distribute diffs other than modifed files?

Standard Unix unified diff format:

$ diff -uw oldfile newfile

I have only tested this CMakeLists.txt to generate Visual Studio project files and build with Visual Studio.

The

Makefile.win32

for VS didn't work? I have seen VS last time ten years ago, but there was always

nmake

included.

It should be straightforward to adapt to other platforms for anyone with experience.

Maybe I could include it, but I don't want to clutter the project with so many different make-tools. Especially not when there are already working ones and when it means an additional file to modify whenever new files are added. It would be nice to keep

make.rules

the only file for all platforms.

[hop]

Originally Posted by phx

Oh, I see! Looks like nonsense. Removed the

= var

in all cases now. Thanks!

Great.

Originally Posted by phx

Standard Unix unified diff format:

$ diff -uw oldfile newfile

Thanks. I'll try to use this.

Originally Posted by phx

The

Makefile.win32

for VS didn't work? I have seen VS last time ten years ago, but there was always

nmake

included.

Yes it does work, so I added the command to the readme. However, it doesn't generate debug information so it was no good for development. To do this for Windows, /Zi must be added to COPTS and /DEBUG to LDFLAGS. I tried modifiying the makefiles to add a debug build, but I got into a bit of a mess.

Originally Posted by phx

Maybe I could include it, but I don't want to clutter the project with so many different make-tools. Especially not when there are already working ones and when it means an additional file to modify whenever new files are added. It would be nice to keep

make.rules

the only file for all platforms.

I don't blame you. CMake is becoming quite ubiquitous now, and I find it very convenient. For example, it generates debug and release configs by default. Its generators know how to build the project files for make, Visual Studio etc. If CMake is available and works on all platforms then it is only a single file to maintain. It might not be worth adding CMakeLists.txt until it has been tested on all platforms - I'll see if I can test them.

[hop]

I have been considering adding an option:

-DISPL=<style>    Displacement style 0=decimal (default), 1=hex, 2=dec if -ve, hex if +ve

I would find this very useful because often the displacements I am reading are relative to $dff000, $bfe001 or $bfd000 (in address registers). The hex offsets that I am used to seeing in debuggers and .i files are far more readable at a glance.

Option 2 might be handy for Amiga LVOs.

Does this sound like a worthwhile addition?