01 October 2021, 10:06 | #21 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,214
|
Which debug info in the Amiga Hunk format would that then be? You can assign an offset relative to a hunk with a symbol, either 32 or 16 relative. This requires two informations: The PC location where it applies to, and the offset value.
|
01 October 2021, 10:16 | #22 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,322
|
I don't know. There is no exact standard with debug hunks, it seems Devpac has its own.
|
01 October 2021, 11:34 | #23 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
The question whether including source texts or linking with their object files is mostly personal preference. Both have minor advantages and disadvantages, even with compiling/assembling times excluded.
Source inclusion has the advantage that assemblers see all labels and can theoretically perform more optimizations (e.g. branches). Object files have the advantage that you don't pollute your name space, except for a few exported symbols. Personally I prefer object file linking, because it feels less messy. I have a clearly defined interface between object files and can easily exchange them between projects (like my trackdisk.o or ptplayer.o). Quote:
Try vasm on an A500... Quote:
Quote:
|
|||
01 October 2021, 13:04 | #24 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
Quote:
Whether a debugger has implemented it doesn't matter, because you said that "a debugger couldn't know that". This is false. It can. |
|
01 October 2021, 13:20 | #25 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
As far as I know there is no debugging format for assembler sources which can do that. The more sophisticated, and undocumented, HUNK_DEBUG blocks are only usable for the C language. Which means in assembler your best option is to enable LINE or HCLN HUNK_DEBUG blocks and hope the debugger shows your original source text for the current PC. Quote:
|
||
01 October 2021, 18:25 | #26 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,214
|
Quote:
Quote:
Not only. This is not a MonAm specific problem, it is a restriction of the debug data DevPac (and other assemblers) can generate - and this is again a restriction because you don't have type information in assembler. In C, it can be done (though with private data in the debug hunks) since the compiler can store types of function arguments in some private fields. But assembler doesn't have all that either. So it is a pretty basic problem of the language. For the records, this is exactly the problem I faced when writing my debugger ("COP"), and the best I could come up are symbols that are relative to some public named node. So you do see members of "struct GfxBase", due to some additional magic around the COP "DDT" files, but for your average assembled or compiled binary, it is simply not possible because there is no database where these symbols could come from, and there is no database either that relates registers to members of structures, and that is because assembler does not have "structures" or "types". |
||
01 October 2021, 21:09 | #27 | |
Registered User
Join Date: Sep 2019
Location: Essen/Germany
Age: 55
Posts: 463
|
Quote:
Theoretically the debugger could provide such information in some cases, but it's probably hard to implement. For well known addresses the debugger would have to keep track of the addresses so it knows which register has a certain base address and then it could apply the appropriate offset label as well. Last edited by SpeedGeek; 01 October 2021 at 21:34. Reason: Fixed inline quote |
|
01 October 2021, 21:28 | #28 | ||||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,543
|
Quote:
IMO the 'best' way is to show the source code line. But I want to see the actual machine code too, as it gives me a better idea of what is really happening. Rather than using line debugging I simply flip back to the editor screen and search for the nearest code label. This works in assembler because the source and machine code mostly matches up line for line. It's not so useful in high level languages because a source code line usually expands to several lines of machine code which may not have an obvious relationship to the source. Quote:
Quote:
If you use the DEVPAC editor you have to split up large source code files because it screws up if there are too many lines in a single file. The project I am working on right now has ~35000 lines in the main source code file (over 1 million characters each individually typed!) and a few thousand lines in include files. It takes ~8 seconds to assemble with ProAsm on a 50MHz 030 (Barfly takes ~5 seconds). I doubt that moving those few thousand lines into object modules and linking separately would make it much faster. I could split up the main source, but changes often have to be made to disparate parts at the same time - which would require editing several files and reassembling and linking them each time. It would also involve more boring typing to add the XREFs and XDEFs, and the result would be a bit less efficient because pc-relative code can't span object modules. On smaller projects there is even less incentive to create object modules and link them separately because the time saved (if any) is even less. However in large projects with highly modular code that doesn't change much (eg. an OS) it has advantages, including maintaining the modularity so others can use the object code without worrying about source code compatibility etc. High level languages often have long compile times, which makes a separate linking stage much faster when only a few source code files need to be recompiled. |
||||
01 October 2021, 22:57 | #29 | ||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,214
|
If the debugger can access the source code, yes. That is not always possible.
Quote:
Quote:
Quote:
Quote:
Side remark:ARexx is just like that, one big pile of mess, assembled with one file that includes a lot of the other sources, with modules that have just numbers, not telling names. Needless to say, it is incredibly hard to maintain this pile of code. Probably that's Bill's revenge against CBM for not having paid him... |
||||
02 October 2021, 20:08 | #30 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
In defense of myself, I would never have dared derail the conversation if Thomas hadn't spoken so categorically. He wrote, "a debugger".
A debugger can show operand symbols like sandruzzo wants. It can be done in three different ways without evaluating them (just as for labels). This debugger doesn't support it. AsmOne, AsmPro and similar have an integrated debugger that can (run-time) show and evaluate operand symbols. |
02 October 2021, 21:20 | #31 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,214
|
|
02 October 2021, 23:08 | #32 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
I have no experience with AsmOne, but I would guess this can only work because the debugger has all information from the previous assembler run available. Definitely an advantage of an integrated assembler-debugger environment. |
||
04 October 2021, 10:06 | #33 | |||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,543
|
Quote:
However I am open to different ways of doing things, so I will try splitting it up to see if that works better. Quote:
I did a small test using blink and it did indeed add 'trampoline' code, and also relocated pc-relative data references. However it seems I need a better linker because it also tried to trampoline data references - and failed spectacularly. Code:
; -- blink tries to 'trampoline' a pc-relative data reference -- Section 0,CODE r000000: lea i00000c(PC),A0 ; <-- supposed to be lea r008018(pc),a0 bsr r000012 rts align.l i00000c: jmp r008018 ; <-- but was 'trampolined' with a jmp! r000012: jmp r00801a ; <--- this one is OK ; -- second object file merged here -- w000018: ds.b 32768 r008018: ; oops! not code! dc.w $1234 r00801a: lea w000018,A0 rts align.l end 'Trampolining' branches only works if there is less than 32k between the branch and the end of the section. This means I will have to split my code up into sections with less than 32k of code in them to ensure the 'trampoline' works. Alternatively I could just change long branches into jmps like I do now, which produces tighter and faster code. Quote:
Splitting code up into separate object files can also be messy. Some Amiga programs that (I presume) were coded by people unfamiliar with advanced linking techniques have a very large number of hunks, sometimes with only a few bytes or nothing in them. AmigaBASIC has 81 hunks. F18-Interceptor has 185 hunks! The source code for that must be 'interesting'. |
|||
04 October 2021, 10:47 | #34 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Each to their own but I suspect you're limiting yourself by using an editor on the A1200, try using modern tools to make development easier and more efficient for yourself. |
|
04 October 2021, 11:38 | #35 | |||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,322
|
Quote:
I might add that when doing code refactoring, source splitting just goes in the way. Quote:
Quote:
Modern tools have the option to show whole parts of the source as single line (you know, with these little "+" at the left), so being multi-files is even less useful here. |
|||
04 October 2021, 11:56 | #36 | ||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,543
|
Quote:
Quote:
|
||
04 October 2021, 12:22 | #37 | |
Registered User
Join Date: Sep 2019
Location: Essen/Germany
Age: 55
Posts: 463
|
Quote:
Wow! 30000 Lines is quite a lot. Well, you have to live with it, so it's your choice anyway. I'm writing some stuff for the C128 and when the code reached about 3000 lines, I already found it quite annoying to have everything in one file and having to scroll up and down all the time, so I started to split it. Even with bookmarks it gets tedious to navigate IMO. |
|
04 October 2021, 14:19 | #38 | ||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,543
|
Quote:
Quote:
I used a PC to develop software for other retro platforms because doing it on the target machine would have been a pain. But not so the A1200. It's a totally different experience from a modern PC, but not a bad one. I love the way it operates and how it feels - the smooth accurate mouse, the big bold display, the multiple screens and efficient multitasking, the comforting click of the floppy drive, the beautiful lines of the wedge-shaped case etc. Programming my Amiga is really just an excuse to play with the machine I love. |
||
04 October 2021, 15:30 | #39 | ||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Quote:
For me it is about getting the most productivity efficiently and as easily as possible. |
||
04 October 2021, 15:41 | #40 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,543
|
Quote:
I am usually only scrolling up and down through one function, so it doesn't matter how big the file is (within reason). However not everything is in a single file. Things like startup code, the file requester, and data that doesn't change are kept in separate files that are included in appropriate places. In my USB BASIC for the Aquarius I split the code into 13 separate files for the different functions (USB driver, DOS, disassembler/monitor, windows, AY player etc.). |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Devpac Debug hunks | phx | Coders. General | 21 | 16 July 2023 08:13 |
Assembler files and C in GCC / bartman's amiga-debug | zero | Coders. C/C++ | 11 | 12 March 2021 16:17 |
Devpac include files? | anotheramigafan | Coders. General | 2 | 21 August 2018 21:44 |
Open '.txt' files in Devpac without CR\LF Characters | Blip | Coders. General | 4 | 11 January 2018 03:46 |
Debugging included files (AsmOne vs DevPac) | nandius_c | Coders. Asm / Hardware | 4 | 24 August 2014 13:19 |
|
|