+cubanismo Posted August 27, 2020 Share Posted August 27, 2020 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted August 27, 2020 Share Posted August 27, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted August 30, 2020 Share Posted August 30, 2020 (edited) 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! Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted August 30, 2020 Share Posted August 30, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted August 30, 2020 Share Posted August 30, 2020 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) Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted August 30, 2020 Share Posted August 30, 2020 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted August 31, 2020 Share Posted August 31, 2020 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) 3 Quote Link to comment Share on other sites More sharing options...
ggn Posted September 1, 2020 Share Posted September 1, 2020 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 :). 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted September 1, 2020 Share Posted September 1, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted September 1, 2020 Share Posted September 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
dilinger Posted September 1, 2020 Share Posted September 1, 2020 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. Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 2, 2020 Share Posted September 2, 2020 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 2, 2020 Share Posted September 2, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted September 2, 2020 Share Posted September 2, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 2, 2020 Share Posted September 2, 2020 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted September 2, 2020 Share Posted September 2, 2020 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 2, 2020 Share Posted September 2, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted September 2, 2020 Share Posted September 2, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted September 2, 2020 Share Posted September 2, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted September 2, 2020 Share Posted September 2, 2020 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! 2 Quote Link to comment Share on other sites More sharing options...
ggn Posted September 2, 2020 Share Posted September 2, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted September 2, 2020 Share Posted September 2, 2020 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 :). Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 2, 2020 Share Posted September 2, 2020 (edited) @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 Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 2, 2020 Share Posted September 2, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
SebRmv Posted September 3, 2020 Share Posted September 3, 2020 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.