Quote:
Originally Posted by meynaf
If code requiring comments is bad, then all code in the world is bad.
|
Sorry, this is so wrong. Maybe look into some books on good programming practise if you don't believe me. Maybe you're not working long enough in the field, maybe your programs are too short or too simple, but thrust me:
Comments are good. Programs requiring comments are bad.
Code should be to a major degree "self-documenting", so something like
Code:
move.l $18(a0),a0 ;cl_Super
is bad, because there is a self-documenting alternative:
Code:
move.l cl_Super(a0),a0
There is an even better alternative. Instead of wasting your time with commenting things that could be self-documenting, write *why* your code does something:
Code:
; ok, method XYZ is not specific to our class, forward it to the super class
move.l cl_Super(a0),a0
....
So, don't waste comments and typing to "obvious" things the assembler can do for you. Instead, comment motivation, structure and design, i.e. "higher level".
In the same vain,
Code:
addq.l #1,d0 ;increment d0
is *bullshit*. It is obvious that this instruction increments d0. Instead, comment *why* you are doing this:
Code:
addq.l #1,d0 ;advance to the next index in the list
as an example.
These principles aren't new, aren't mine...
Quote:
Originally Posted by meynaf
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.
|
Use better tools. Seriously. The WinUAE debugger is... sorry Tony... not usable. It is a "last resort", but not a tool for program development. Use a debugger that works and offers the right tools. Source level debugging, I named it already.
Quote:
Originally Posted by meynaf
No support for basereg. Optimisation level of branches very poor. Very slow to assemble. Etc, etc.
|
Low-level optimizations: Don't waste your time with that. Not worth it. Algorithms make programs fast. Not micro-optimizations. "basereg" you can certainly do with DevPac - you just have to organize your "data section" accordingly. I don't see that the assembly speed is in any sense critical at all.
Quote:
Originally Posted by meynaf
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.
|
MonAm cannot. But it is rarely needed. I'm using COP for this, but this is a "last resort", and not something I would design my "coding style" for - this is the wrong way around.
Quote:
Originally Posted by meynaf
And i'm not talking about OS killing programs...
|
Don't kill the Os. The Os is your friend, not your enemy.
Quote:
Originally Posted by meynaf
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.
|
A lot of people do crazy stuff. Again, the way how I see it, it is not a debugger for development. For me, this sounds like masochism.
Quote:
Originally Posted by meynaf
There is nothing wrong in using the numbers in asm programs, really.
|
There is a lot wrong with that. Just unreadable, unmaintainable programs, and I'm doing this for a long time.
Quote:
Originally Posted by meynaf
It has always worked fine and always will. It's a magnitude more lean and mean.
|
Nope. Changing your style is hard, but the change is worth it. Just try.
Quote:
Originally Posted by meynaf
And of course, when it comes to resourcing (= disassemble programs and reassemble them), knowing the (most common) numbers helps a lot.
|
I was talking about development. Not "cracking" or "resourcing".
Quote:
Originally Posted by meynaf
Consider this : as long as you use a good enough assembler, my code can readily assemble on any setup.
|
And got lost in details, and hours of debugging. Not my type of fun.
Quote:
Originally Posted by meynaf
No path in sources, no incdir mess, no special config required, no version conflicts, no need to have anything particular installed.
|
include and incdir are not a mess. They are development necessities for non-trivial programs. Proper includes, proper makefiles, and a linker phase. As soon as a program becomes large enough, it becomes necessary to structure your work. These tools help to structure your work.
It seems, at the start, as if this is more work, but the invested time pays of very soon, you just have to start right from the beginning.
Btw what is your motivation here ? Warning me is something, insisting is something else.[/QUOTE]