RMAC/RLN

[+cubanismo]

On 8/3/2020 at 9:04 AM, cubanismo said:

Any interest in a small patch to accept ":" as a command separator in addition to ";"? 

I've submitted a patch to do this: http://jlhconsulting.gotdns.com/bugs/show_bug.cgi?id=172

 

@ggn, you also broke RMACPATH with your fix for the mulitple-directories-via-command-line issue ?  I submitted a patch in bug 171.

[ggn]

8 hours ago, cubanismo said:

I've submitted a patch to do this: http://jlhconsulting.gotdns.com/bugs/show_bug.cgi?id=172

 

@ggn, you also broke RMACPATH with your fix for the mulitple-directories-via-command-line issue ?  I submitted a patch in bug 171.

Well, you got me there. I thought about checking the code for RMACPATH but thought "It's probably fine, besides: who even uses RMACPATH"? Well, now we know!

 

Thanks!

[+cubanismo]

OK, here's a fun one.  I've filed this bug http://jlhconsulting.gotdns.com/bugs/show_bug.cgi?id=173

 

I can't get the latest rmac to properly compile the bpeg decoding routines in bpeg.s from Brainstorm.  Given qUaKe exists, I assume it worked at some point, unless you guys were using mac in dosbox for that.  My theory based on partial debugging is that rmac is getting confused while resolving the fixup for an expression that takes the difference of two labels, and leaves it marked as requiring a relocation, but I don't know how I'm supposed to deduce in the expression evaluator (fun reading, gave up) that the difference between two defined symbols does not require a relocation, nor how to pass that data back up to the fixup code, where it would presumably clear the "tdb" flag or something similar.  Incidentally, both symbols have absolute addresses anyway, so I don't see why they'd need to be relocatable in the first place even if they weren't used in an expression, but both mac and rmac seem to record relocations for such symbols used stand-alone, so maybe I'm misunderstanding how relocations work in general.

Edited August 30, 2020 by cubanismo
Always one more typo, and wrong bug link!

[LinkoVitch]

Assuming I am understanding what you are doing (I think you might have pasted the wrong bug link BTW) I think the current version or RMAC does work correctly for calculating the difference between two labels.  I have the following code in the SE

 

.pc:	move	PC, JUMPTO
	addq	#(mainloop - .pc), JUMPTO	

to calc a branch to the main loop, and that is working fine for me. 

[+cubanismo]

Yes, it's quite a common construct, so I'm surprised it would break.  The code in question is this:

 

.68000

...

 lea ZZQTLMatrix-BPEGStartUp(a5),a3  <-- Generates bad relocation

...

.gpu

.org myaddr

...

BPEGStartUp:

    <gpu code>

...

ZZQTLMatrix   .equ     *

 

So perhaps it's the fact that it's a .equ to the current location pointer rather than a simple label, but functionally they should be equivalent.  They're basically using .equ + '*' to generate a BSS section in their GPU code:

 

ZZQTLMatrix     .equ    *                       ; Luminance Quantization Matrix ($100 Bytes)

ZZQTCMatrix     .equ    *+$100                  ; Chrominance Quantization Matrix ($100 Bytes)

MCUBuffer       .equ    *+$200                  ; I/O MCU Buffer ($600 Bytes)

MCUTmpBuffer    .equ    *+$800                  ; Inv. DCT Temporary Buffer ($100 Bytes)

[+cubanismo]

Hmm, that theory suggests a workaround:

 

ZZQTLMatrix    .equ     *                      ; Luminance Quantization Matrix ($100 Bytes)

ZZQTCMatrix     .equ    *+$100                  ; Chrominance Quantization Matrix ($100 Bytes)

MCUBuffer       .equ    *+$200                  ; I/O MCU Buffer ($600 Bytes)

MCUTmpBuffer    .equ    *+$800                  ; Inv. DCT Temporary Buffer ($100 Bytes)

 

Can be rewritten like this:

 

ZZQTLMatrix:                       ; Luminance Quantization Matrix ($100 Bytes)

ZZQTCMatrix     .equ    ZZQTLMatrix+$100                  ; Chrominance Quantization Matrix ($100 Bytes)

MCUBuffer       .equ    ZZQTLMatrix+$200                  ; I/O MCU Buffer ($600 Bytes)

MCUTmpBuffer    .equ    ZZQTLMatrix+$800                  ; Inv. DCT Temporary Buffer ($100 Bytes)

 

And that does in fact result in rmac producing an identical object file to mac!  So I suppose this is down to rmac's '*' handling?  I believe there's an existing bug open for that.

[ggn]

Just to give an update: This is in the process of being fixed. Actually, there is a fix right now but it breaks other cases.

 

(2020 is going to be the year of bad symbol exports by the looks of it)

[ggn]

Aaaaand we're probably fine now. Just waiting for Shamus to confirm and commit the fix and a new version will be released.

 

For the impatient, grab the patch and build the assembler yourself :).

[ggn]

On 7/29/2020 at 9:52 PM, dilinger said:

Hi,
I think I've found an issue with RLN V1.6.1.
If the options related to symbols are not used, the PSymbolTable and NumberOfSymbols fields in the coff will still be set.
It will create a problem if the fields are used by a tool or a debugger, because no symbols will be found in the file.
Could it be possible to fix this problem?
If the source code is available on Git, please let me know, I will try to have a look at the issue.

Hi there, I've added a fix for the issue you raised on the issue tracker. If you could compile and test rln, it'd be great.

Edited September 1, 2020 by ggn
BBderp

[+cubanismo]

2 hours ago, ggn said:

Aaaaand we're probably fine now. Just waiting for Shamus to confirm and commit the fix and a new version will be released.

 

For the impatient, grab the patch and build the assembler yourself :).

As noted on the bug, I've tested & confirmed the fix on my end.  Thanks!  Hopefully I'll be able to have patches in hand for the inevitable next report.  Learned a lot while stumbling around on this one.

[dilinger]

3 hours ago, ggn said:

Hi there, I've added a fix for the issue you raised on the issue tracker. If you could compile and test rln, it'd be great.

Hi. Sure. I have applied the patch and tested, the issue is mostly fixed. I have added a comment in the issue tracker. Thanks.

[SebRmv]

Hello,

 

I am trying to switch to rmac for building The Removers Library.

 

I get the following errors when compiling display.s:

 

display.s 192: Error: illegal relative address
display.s 192: Error: mis-nested .endr

 

First, I believe the line numbers are wrongly reported, because on line 192 stands a local label definition:

.gpu_display_from_cpu_it:

 

Secondly, the second error message seems to indicate a problem with a rept/endr.

 

Is there a way to adapt code that was accepted by MadMac?

 

How can I track more precisely the origin of the error?

 

Many thanks!

 

Seb

 

Edited September 2, 2020 by SebRmv

[SebRmv]

I think one problem in my code is the use of '*' to refer to current PC, as for instance in the following code:

 

.org G_RAM
padding_nop	(G_RAM+$10-*)

 

where padding_nop is a macro defined as follows:

 

.macro	padding_nop
	.print	"adding ",\1/2," padding nop"
	.rept	(\1 / 2)
	nop
	.endr
.endm	

 

What should I use instead of '*' ?

 

 

Edited September 2, 2020 by SebRmv

[+BitJag]

You or @ggn can confirm if this was the same issue I ran into when first getting rmac to build the rmvlib source.  In order to get the build to happen ggn had me make some minor changes to display.s, paula.s, sound.s in the rmvlib source.  Described below.  Making these changes allows rmac V2.0.12 to properly build rmvlib.  I don't know if the recent adjustments to rmac for other bugs may have changed things.  I haven't tried building rmvlib recently.

 

display.s 

line 150 -                      padding_nop    (G_RAM+$10-*)

change to -                   padding_nop    (G_RAM+$10-pc1)

Add one line before -    pc1=*

 

line 169 -                      padding_nop    (G_RAM+$40-*)

change to -                   padding_nop    (G_RAM+$40-pc2)

Add one line before -    pc2=*

 

sound.s

line 122 -                      padding_nop    (D_RAM+$20-*)

change to -                   padding_nop    (G_RAM+$20-pc1)

Add one line before -    pc1=*

 

paula.s

line 67 -                      padding_nop    (D_RAM+$10-*)

change to -                   padding_nop    (G_RAM+$10-pc1)

Add one line before -    pc1=*

 

The pattern is clear, but I have no idea what is going on, I just know that this was one of the few things I had to do to get things building on my end a few months ago.  I have a shell script that automates downloading and building rmac, rln, and the Removers Library in linux with access to the ubuntu repositories for the cross compiler now, so I don't have to make these changes manually anymore.  The script is pretty simple and should be easy to parse on your own if you run into problems.  https://github.com/lachoneus/ubuntu-rmvlib-install-scripts

[SebRmv]

Ok, many thanks! Will try that

 

edit: just tried, display.s still fails to be assembled (not tried the other files, but I guess it's the same issue)

 

Edited September 2, 2020 by SebRmv

[+cubanismo]

I'm curious whether @ggn's patches for the issue I reported remove the need for the changes to rmvlib source as well.  Long shot, but it seems at least possible they're related.  If it's just bad handling of '*' in an expression, probably won't help, but if rmac was actually getting confused about whether '*' was relative or absolute, it could, as that's the issue I was having building bpeg.s.

 

Here's a direct link to the rmac patch:

 

http://jlhconsulting.gotdns.com/bugs/attachment.cgi?id=144

Edited September 2, 2020 by cubanismo
added link to patch

[SebRmv]

13 minutes ago, cubanismo said:

I'm curious whether @ggn's patches for the issue I reported remove the need for the changes to rmvlib source as well.  Long shot, but it seems at least possible they're related.  If it's just bad handling of '*' in an expression, probably won't help, but if rmac was actually getting confused about whether '*' was relative or absolute, it could, as that's the issue I was having building bpeg.s.

 

Here's a direct link to the rmac patch:

 

http://jlhconsulting.gotdns.com/bugs/attachment.cgi?id=144

I applied the patch and it seems to work! Thanks

I need to test, test and test now

[+BitJag]

Not to confuse things, but there was one more alteration that needed to be made to rmac along with the other changes to the the removers source files.  It seems that the patch linked to by @cubanismo might do a similar kind of change I haven't dug into the patch yet to see for sure.  Here is the change I was performing to the expr.c in the rmac source back in March/April of 2020, as suggested by ggn if I remember right, to get rmac to build things.  

 

sed -i '/_attr = cursect | D/c\*a_attr = DEFINED;' expr.c

 

This bit of code in the script makes the following change:

 

expr.c

Line 466

From -  *a_attr = cursect | DEFINED;

To -       *a_attr = DEFINED;

 

I just tested the latest rmac, jlibc, and rmvlib with this change and the changes to the rmvlib source mentioned above, and everything seems to build correctly.

[+cubanismo]

And does it work without the changes to the rmvlib source?  That change does look as though it's very likely obsoleted by the latest fix from ggn I linked.

[+BitJag]

Just now, cubanismo said:

And does it work without the changes to the rmvlib source?  That change does look as though it's very likely obsoleted by the latest fix from ggn I linked.

Thanks for the followup question, I didn't think that the patch would also make the changes to the rmvlib source obsolete as well. 

 

Just tested everything out to confirm @SebRmv results.  The patch provided by @cubanismo builds rmac, jlibc, and rmvlib without all of the quick fix changes I was doing 6 months ago to rmac and rmvlib. 

 

Time to update my shell script.  Thanks everyone for the continued updates to rmac!

[ggn]

Awww shucks guys, you're the best! I opened the page and saw half a page's worth of new messages and thought I'd have to spend a few hours testing things, but everything was resolved at the end :).

 

A couple of notes: 

9 hours ago, SebRmv said:

How can I track more precisely the origin of the error?

I thought I fixed the issues with error reporting while evaluating macros and REPTs, but it seems it's not perfect yet. I'll have another go at it. In the meantime an accurate way to pinpoint the expanding issues is to produce a listing (switch -l or -l* if you prefer no pagination).

 

As for the rest of the patches, hopefully @Shamus will get around to integrating them into the repository so people don't have to do magic hocus pocus all the time, but grab a binary instead and do some work

 

@SebRmv thanks for trying out rmac and don't hesitate to report any issues!

[ggn]

Also, I just submitted a patch for the macro issues that @SebRmv has. Hopefully it will be merged with the main tree, in the meantime the adventurous can try it out for themselves :).

[SebRmv]

@ggnI think it is time that I use a more modern tool than MadMac

 

I will report issues if I found any, be reassured

 

It would be great if the patch is integrated to rmac github repo. By doing so, I will be able to officially switch to rmac all my projects.

Edited September 3, 2020 by SebRmv

[SebRmv]

3 hours ago, cubanismo said:

And does it work without the changes to the rmvlib source?  That change does look as though it's very likely obsoleted by the latest fix from ggn I linked.

Yes, with the patch to rmac, no need to modify rmvlib

[SebRmv]

Where should I report bugs?

 

;;; address register = base of var array
VARREG	equ	2

.macro	emitInstr
	;; \1 = instruction
	move.w	\1,(a1)+
.endm

.macro	emitTgtMem
	;; \1 = opcode
	;; \2 = variable number (will be multiplied by 2)
	;; \3 = address register number	
	add.w	\2,\2
	beq.s	.opt\~
	emitInstr	#(\1)|(%101<<6)|((\3)<<9)
	bra.s	.done\~
.opt\~:
	emitInstr	#(\1)|(%010<<6)|((\3)<<9)
.done\~:
.endm

	;; emit "move.w #YYyy,xx(Var)"
	emitTgtMem	(%0011<<12)|(%111100),d0,VARREG

This one produces a segmentation fault.