Quote:
Originally Posted by Thomas Richter
Do you think you will keep comments updated all the way? Comments on code are good, but code requiring comments is bad. Just use the tools of the language to make things obvious, then you can keep the comments for things that are worth commenting.
|
Aside of all this being completely OT, these comments do not need to be "updated". They are here, period. It's not as if these values could change overnight !
If code requiring comments is bad, then all code in the world is bad.
If you think some code is obvious and is not worth commenting, think twice. Chances are good you are making a mistake.
A comment that is there but not very useful isn't a problem. A comment that's NOT here where there should be one is a lot more problematic.
Quote:
Originally Posted by Thomas Richter
The source level debugging information is rather generic, it would surprise me if other assemblers cannot create it as well.
|
Well, perhaps they can. And perhaps i don't want to bloat the thing with this kind of irrelevant info.
Besides, the source could be anywhere, including in an editor that's not even running on the Amiga (i.e. opened in np++ while the code is in debug in winuae - in windowed mode i can see both together). Altering the source as mistakes are found make said source obsolete in regard to any source level debugging.
Quote:
Originally Posted by Thomas Richter
I don't know what you need, but DevPac is a rather powerful tool.
|
No support for basereg. Optimisation level of branches very poor. Very slow to assemble. Etc, etc.
I need a debugger that can trace into a function that's in input.device context (like the hook of a class). For obvious reasons Devpac can't do this.
And i'm not talking about OS killing programs...
Note that even though it's not my case, many coders use winuae's built-in debug facilities, of course without any source level possibilities.
Quote:
Originally Posted by Thomas Richter
Let it be what it is, what you do here is "shooting yourself into the foot".
|
Nope. Remember this is asm ; in C i would indeed use the names.
There is nothing wrong in using the numbers in asm programs, really. It has always worked fine and always will. It's a magnitude more lean and mean.
And of course, when it comes to resourcing (= disassemble programs and reassemble them), knowing the (most common) numbers helps a lot.
Consider this : as long as you use a good enough assembler, my code can readily assemble on any setup. No path in sources, no incdir mess, no special config required, no version conflicts, no need to have anything particular installed.
Btw what is your motivation here ? Warning me is something, insisting is something else.