Devpac Debug Issue with multiple files

[Thomas Richter]

Originally Posted by Bruce Abbott

I like it that way because I only have to open one file and know what I want to work on is in there.

Except if the file gets too long, which it already is. If you have clear modules, you also know in which module to look. Ideally, "one file, one responsibility".

Originally Posted by Bruce Abbott

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.

It obviously cannot do that for data entries. How should it work? If you access data relative to the PC, and the target data is out of range, the linker cannot modify your code and replace your PC-relative reference by an absolute reference. Trampoline code is for... code.



PC-relative addressing is for constant data close to the PC, typically strings. If you need "data storage on the heap", then PC-relative is not the right addressing mode anyhow. base-register relative for small data, or absolute for large data, either in a separate hunk, or allocated upon startup if you prefer pure (as in "resident-able") code.



Slink will create an error in case ALVs are required to access data.

Originally Posted by Bruce Abbott

'Trampolining' branches only works if there is less than 32k between the branch and the end of the section.

Shorten the modules. As already said, that's a good idea anyhow. It requires you to organize the code, and that's a good idea by itself.

Originally Posted by Bruce Abbott

Or perhaps he just prefers to code that way.

That's not the only "style issue" with the code. About 80% of the rexxsyslib.library is pretty useless (at least for any higher programming language) because it uses dual return codes, return codes in condition registers and other assembly-only features. Well, and it is utterly useless because it is utterly undocumented....


It's pretty much an alien to the rest of the system (well, maybe along with graphics whose built-system is also a mess).

Originally Posted by Bruce Abbott

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'.

Not at all. Apparently, the built-system they used created one separate hunk per translation unit, so there is nothing really strange about that. There are advantages and disadvantages on many hunks. The disadvantage is that it takes longer to load and requires more relocation information. The advantage is that it may load even if the main memory is pretty fragmented, which was an issue with the tiny RAM the A1000 came with. Today, this is not really an issue anymore.



Amiga Basic aka "Microsoft Basic" is more or less a straight port from Mac, and probably half assembler and half C.

[Thomas Richter]

Originally Posted by Bruce Abbott

Once you get past a few screens it doesn't matter - whether it's 300 lines or 30000 lines you still have to scroll 'all the time' to get where you want to be.

"Scrolling" is not quite the argument. "Code organization" is the argument. If you have just "one pile of code" without clear responsibilities, it becomes pretty hard to maintain such code later on. Ideally, you define interfaces between the modules, and give each file as each function a clear responsibility.


In C++, it's ideally "one file, one class", and you can mimic this in assembler as well.

[sparhawk]

Originally Posted by Thomas Richter

In C++, it's ideally "one file, one class", and you can mimic this in assembler as well.

In my C++ code I usually follow this paradigm. On the C128 I didn't do it because it was at the beginning a rather hands-on project, but as it grew it became more and more apparent that it gets harder to maintain already.

Compile time doesn't matter in this case because the generation is so fast that it doesn't reall matter one way or the other.
However, I find it nice when I finished a module (i.E. Keyboardhandling) it's in a seperate file and I don't have to touch it again until I find a bug or need to improve it. It doesn't clobber up my current file and I can let it out of my head because it's finished.

[Bruce Abbott]

Originally Posted by Thomas Richter

It obviously cannot do that for data entries. How should it work?

It should throw an error, not silently add trampoline code that doesn't work.

PC-relative addressing is for constant data close to the PC, typically strings.

That's all I use it for (my example code only has ds.b for testing).

Slink will create an error in case ALVs are required to access data.

This might be the linker I need then.

Shorten the modules. As already said, that's a good idea anyhow. It requires you to organize the code, and that's a good idea by itself.

My code is organized, just not in separate files.

That's not the only "style issue" with the code. About 80% of the rexxsyslib.library is pretty useless (at least for any higher programming language) because it uses dual return codes, return codes in condition registers and other assembly-only features.

The horror!

and it is utterly useless because it is utterly undocumented....

That's bad. My code is documented on almost every line (for my own benefit as much as anyone else).

But it seems to be the trend these days. Most of the 'modern' source code I have looked at has a ton of 'boilerplate' at the start, but little or no description of what the code does or how it works, and barely a single comment in sight thereafter. And dozens of files that are little more than stubs, which you have to wade through trying to figure out what some function actually does.

Not at all. Apparently, the built-system they used created one separate hunk per translation unit, so there is nothing really strange about that.

Many of those hunks have nothing in them, others might be a single longword. Whatever you think of the system they used, it's not efficient.

Amiga Basic aka "Microsoft Basic" is more or less a straight port from Mac, and probably half assembler and half C.

Yes, it looks like some of it is assembler and the rest is C.

Sadly it appears to use the upper 8 bits of addresses for something else, which makes it fundamentally incompatible with 32 bit systems. Commodore were right not to pay Microsoft for this dross! It's a pity because the top level design was rather nice (certainly much better than any 8 bit BASIC I have used) and it has excellent support for Amiga system functions. Some day I hope to finish patching it to at least work properly on a stock A1200 with FastRAM.

[Thomas Richter]

Originally Posted by Bruce Abbott

It should throw an error, not silently add trampoline code that doesn't work.

BLink is quite a bit outdated and unmaintained. SLink fixed that. I don't know about vlink.

Originally Posted by Bruce Abbott

My code is organized, just not in separate files.

So it's not very well organized, essentially. (-;

Originally Posted by Bruce Abbott

The horror!

If you want to use them from any language but assembler, then that makes the calls pretty useless. Well, despite many of them also use the Rexx error reporting and forwarding functions in case something goes wrong, which is also only usable from assembler.

Originally Posted by Bruce Abbott

That's bad. My code is documented on almost every line (for my own benefit as much as anyone else).

That does not necessarily mean good documentation or organization. Organization means "structured in clear responsibilities with well-documented interfaces between them".

Originally Posted by Bruce Abbott

But it seems to be the trend these days. Most of the 'modern' source code I have looked at has a ton of 'boilerplate' at the start, but little or no description of what the code does or how it works, and barely a single comment in sight thereafter. And dozens of files that are little more than stubs, which you have to wade through trying to figure out what some function actually does.

Result of the "scrum development model" likely. Hack down code, debug it, then forget it. Google GWT was like that... Unless you knew which html elements it generated and how those worked, the specs were pretty useless.

Originally Posted by Bruce Abbott

Sadly it appears to use the upper 8 bits of addresses for something else, which makes it fundamentally incompatible with 32 bit systems.

I said it was a direct port from MacOs Microsoft basic. MacOs (the ancient versions) uses the 8 upper bits for the "handle state information", that is, whether a handle (essentially a pointer to a memory pointer, a "pointer to a resource") is locked or migrated. MacOs does have resource management, unlike AmigaOs, and it is quite elaborate, but not very forward-looking in its design.

Originally Posted by Bruce Abbott

Commodore were right not to pay Microsoft for this dross! It's a pity because the top level design was rather nice (certainly much better than any 8 bit BASIC I have used) and it has excellent support for Amiga system functions. Some day I hope to finish patching it to at least work properly on a stock A1200 with FastRAM.

Why? 16MB is supposed to be enough for everyone, right?



MacOs fixed the handle issues pretty soon, and there was also a 2.x beta version of Microsoft Basic (there are hints on beta test reports on it in the CBM bug tracker database), but it MS wanted to charge CBM 1$ per sold copy, and CBM went cheap and ditched the project.



If you want to "fix" that, then be prepared for quite a challenge because the entire memory management has to be redone. Read "Inside macintosh" to get an idea what these "upper bits" are supposed to mean.

[Bruce Abbott]

Originally Posted by Thomas Richter

If you want to use them from any language but assembler, then that makes the calls pretty useless. Well, despite many of them also use the Rexx error reporting and forwarding functions in case something goes wrong, which is also only usable from assembler.

Revenge of the asm coder!

We have to conform to the conventions of 'any other language' when interfacing to it, so...

Why? 16MB is supposed to be enough for everyone, right?

AmigaBASIC has other issues apart from being restricted to 16MB that prevent it from working on later model Amigas.

You may say "why bother?" but I have fond memories of programming in AmigaBASIC on the A1000, so for me it's another part of the 'retro' experience that I would like to explore (eg. imagining a '2.x' version that worked on newer machines).

If you want to "fix" that, then be prepared for quite a challenge because the entire memory management has to be redone. Read "Inside macintosh" to get an idea what these "upper bits" are supposed to mean.

Thanks for that. AmigaBASIC works inside the normal Amiga OS environment, so I figure it can't be that hard to 'fix'.

ETA:

Oh oh!

Inside Macintosh

"The best guide to the Mac's ROMs is Inside Macintosh. Unfortunately, Inside Macintosh is also the most incomprehensible documentation ever written."

[sandruzzo]

With Winuae and the ability to push Processor further, Assembling code isn't anymore an issue: on "My" 040 at 100mhz that it's like a piece of cake.

So, the real deal it's only debugging, that needs to be flawless, otherwise will be a pain in the ass

[Thomas Richter]

Originally Posted by Bruce Abbott

We have to conform to the conventions of 'any other language' when interfacing to it, so...

It's not really "any other language". There are not many languages with multiple return codes.... besides, it violates the conventions of the Amiga system libraries.

Originally Posted by Bruce Abbott

Oh oh!

Inside Macintosh

"The best guide to the Mac's ROMs is Inside Macintosh. Unfortunately, Inside Macintosh is also the most incomprehensible documentation ever written."

Actually, this is the consolidated edition. You'll need the "phone book edition" for the information on the handle bits. It might be hard to find these days.



Actually, I do not find these books hard to read, but what's hard about them is that MacOs has also a couple of inconsistencies as it uses three different calling conventions. Assembler, Pascal and C, depending on the system trap you use, passing rules are different. AmigaOs libraries use one convention (exception: ARexx, and Dos/Tripos for using data registers for pointers and the BPTRs).


MacOs "QuickDraw" (approximately Amiga "graphics.library") is an odd-ball that it keeps its own list of globals in the "a5 world", a construction no other MacOs manager uses. Concepts of quick-draw are fine and well thought about, but the technical integration into the Os is... weird.

[Thomas Richter]

Originally Posted by sandruzzo

With Winuae and the ability to push Processor further, Assembling code isn't anymore an issue: on "My" 040 at 100mhz that it's like a piece of cake.

So, the real deal it's only debugging, that needs to be flawless, otherwise will be a pain in the ass

The issue is not so much assembling stuff. It's managing stuff, and "needing the debugger". If the thing is properly maintained, you wouldn't need the debugger so often.

[phx]

Originally Posted by Thomas Richter

BLink is quite a bit outdated and unmaintained. SLink fixed that. I don't know about vlink.

vlink is certainly maintained, but its maintainer felt no sufficient urge to implement ALVs, although he already did that in PhxLnk. Personally I prefer to shuffle the object modules around to make the BSRs work or replace them by JSRs. An ALV introduces overhead.
But it's on my list.