English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 01 December 2020, 19:48   #1
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
DoSuperMethodA without amiga.lib side posts

Mod note: problematic posts moved from http://eab.abime.net/showthread.php?t=104863
***********************************************************************



Look, do you think in 5 years from now, you remember what $18 was? For debugging, there is source level debugging, MonAm supports that.

Last edited by lilalurl; 05 December 2020 at 10:08.
Thomas Richter is offline  
Old 01 December 2020, 20:46   #2
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
Look, do you think in 5 years from now, you remember what $18 was? For debugging, there is source level debugging, MonAm supports that.
What do you think the comment to the right of the value is for ? It will still be here 5 years from now.
And for source level debugging with MonAm i assume you need to assemble the code with GenAm otherwise it doesn't get the info it needs. And in turn this will fail because GenAm does not have half the features i need/use.
meynaf is offline  
Old 02 December 2020, 08:35   #3
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
What do you think the comment to the right of the value is for ?
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.


Quote:
Originally Posted by meynaf View Post
And for source level debugging with MonAm i assume you need to assemble the code with GenAm otherwise it doesn't get the info it needs.
The source level debugging information is rather generic, it would surprise me if other assemblers cannot create it as well.


Quote:
Originally Posted by meynaf View Post
And in turn this will fail because GenAm does not have half the features i need/use.
I don't know what you need, but DevPac is a rather powerful tool. Let it be what it is, what you do here is "shooting yourself into the foot".
Thomas Richter is offline  
Old 02 December 2020, 10:19   #4
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
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 View Post
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 View Post
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 View Post
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.
meynaf is offline  
Old 02 December 2020, 13:19   #5
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
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 View Post
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 View Post
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 View Post

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 View Post


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 View Post



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 View Post




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 View Post
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 View Post

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 View Post
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 View Post
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]
Thomas Richter is offline  
Old 02 December 2020, 14:14   #6
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
Sorry, this is so wrong. Maybe look into some books on good programming practise if you don't believe me.
Arguments from authority never work on me.


Quote:
Originally Posted by Thomas Richter View Post
Maybe you're not working long enough in the field, maybe your programs are too short or too simple, but thrust me:

Totally ridiculous. Perhaps i work in the field for as long or even longer than you do.
My programs may be short and simple, but they do as much work as bigger programs do, and faster.


Quote:
Originally Posted by Thomas Richter View Post
Comments are good. Programs requiring comments are bad.
All programs require comments.
But some bozos think their code is self-documented enough, and then the reader does not understand a thing when reading it. How many times did i find whole sources without even a comment saying what the source itself is for ! Is THAT the way of coding you want ME to use ??


Quote:
Originally Posted by Thomas Richter View Post
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
You want to go this way ? You won't win. What about :
Code:
 move.l $18(a0),a0       ; access to parent class pointer (cl_Super)
"self documented" is an illusion.


Quote:
Originally Posted by Thomas Richter View Post
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
....
Stop taking me for a fool.
Of course i document why the code does something. All interfaces are fully documented, all routines tell what they do, etc.


Quote:
Originally Posted by Thomas Richter View Post
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".
The assembler can *not* do it for me. Does it fetch these values automatically without me having to provide some include files ? No, it does not.


Quote:
Originally Posted by Thomas Richter View Post
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...
... and are obvious, but don't support your point in any manner.
This strategy is called the strawman fallacy.
I have never written such bogus comments such as you show above.


Quote:
Originally Posted by Thomas Richter View Post
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.
Tell that to all the ones using it. You'll have many foes then.
Not that i'm using it myself, i wrote my own many years ago.


Quote:
Originally Posted by Thomas Richter View Post
Low-level optimizations: Don't waste your time with that. Not worth it.
This is exactly the reason why the assembler should compute the size of branches, not me. And Devpac fails miserably to do so - even worse, it gives errors when branches don't fit, leading to a big big waste of time.
I started 68k asm with devpac2 many years ago and will NEVER return to that. And no, devpac3 isn't better.


Quote:
Originally Posted by Thomas Richter View Post
Algorithms make programs fast. Not micro-optimizations.
Algorithms make programs fast. Micro-optimisations make them even faster. My picture viewer is the fastest currently available, and it's not for nothing.


Quote:
Originally Posted by Thomas Richter View Post
"basereg" you can certainly do with DevPac - you just have to organize your "data section" accordingly.
Change everything just to use the wrong tool ? No way.


Quote:
Originally Posted by Thomas Richter View Post
I don't see that the assembly speed is in any sense critical at all.
But with very large programs it is.


Quote:
Originally Posted by Thomas Richter View Post
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.
Of course MonAm cannot. My debugger can.
I didn't design my coding style just for this, it's one of the reasons - no more, no less.
But even though rarely needed, in our case here it really is !


Quote:
Originally Posted by Thomas Richter View Post
Don't kill the Os. The Os is your friend, not your enemy.
I know. But it's not necessarily *my* program i wish to trace...


Quote:
Originally Posted by Thomas Richter View Post
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.
This is the way you see it. Not the way everyone see it.

Besides, instead of criticizing my way of coding, you could be helpful again and tell me the best way to force the rendering to use coordinates relative to the gadget and not to the window ? The provided RastPort doesn't do that.


Quote:
Originally Posted by Thomas Richter View Post
There is a lot wrong with that. Just unreadable, unmaintainable programs, and I'm doing this for a long time.
They are perhaps unreadable and unmaintainable for you, but it perfectly suits me. Sorry if i can do things you can't


Quote:
Originally Posted by Thomas Richter View Post
Nope. Changing your style is hard, but the change is worth it. Just try.
What makes you think i didn't try and just rejected the option ?


Quote:
Originally Posted by Thomas Richter View Post
I was talking about development. Not "cracking" or "resourcing".
I didn't mention cracking. Why do you insist upon having me say things i haven't ?
But resourcing, yes, it's just a different way to go into other people's code. Does maintaining someone else's program count as "development" for you ? If yes, resourcing is the same.


Quote:
Originally Posted by Thomas Richter View Post
And got lost in details, and hours of debugging. Not my type of fun.
Frankly, you're making a mountain out of a molehill.


Quote:
Originally Posted by Thomas Richter View Post
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.
No, these tools just make me waste time for stupid things that are otherwise straightforward. Structuring the code doesn't need that.
(In many cases i had to use a linker, etc, for other reasons, and it has always been a PITA.)


Quote:
Originally Posted by Thomas Richter View Post
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.
Yes it is more work, and no the invested time doesn't pay.
I know and have tried both options. Can you say the same ?
meynaf is offline  
Old 02 December 2020, 14:34   #7
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
Arguments from authority never work on me.
There are people that have a bit more experience in programming than you. And me, of course. These aren't my advices, actually. You can check a couple of other sources if you like, or don't trust me.



Frankly, you have no clue.


Quote:
Originally Posted by meynaf View Post
Is THAT the way of coding you want ME to use ??
I want you to comment what's worth commenting, and use clear code structure otherwise. I can only repeat: Many comments are good, code requiring many comments is bad. Your "anti-style" requires many comments, which is bad. Instead, comment non-obvious stuff.


Quote:
Originally Posted by meynaf View Post


The assembler can *not* do it for me. Does it fetch these values automatically without me having to provide some include files ? No, it does not.
Include files are fine. Where is the problem with that? They modularize the code.




Quote:
Originally Posted by meynaf View Post

... and are obvious, but don't support your point in any manner.
This strategy is called the strawman fallacy.
I have never written such bogus comments such as you show above.

Code:
move.l $18(a0),a0 ;cl_super
is a bogus comment. Just write the label. Be done with it. This comment is not needed, and pointless. Use the label in first place, that's why we have include files.


Quote:
Originally Posted by meynaf View Post


Tell that to all the ones using it. You'll have many foes then.
Not that i'm using it myself, i wrote my own many years ago.
Until you write code within a team, or need to maintain code from somebody else.




Quote:
Originally Posted by meynaf View Post



This is exactly the reason why the assembler should compute the size of branches, not me.
Nobody should. It doesn't really matter.



Quote:
Originally Posted by meynaf View Post



Algorithms make programs fast. Micro-optimisations make them even faster. My picture viewer is the fastest currently available, and it's not for nothing.
You look at the wrong side of the problem. The instructions aren't the problem. You loose the full picture the way you look at the problem, and that's the danger.




Quote:
Originally Posted by meynaf View Post




They are perhaps unreadable and unmaintainable for you, but it perfectly suits me. Sorry if i can do things you can't
Leave the program aside, look at it in 5 years from now. Live and learn. That's all I can tell. Give the program to somebody else, ask somebody else to maintain it, or to debug it.





Quote:
Originally Posted by meynaf View Post





Yes it is more work, and no the invested time doesn't pay.
I know and have tried both options. Can you say the same ?
Yes, I can say the same. I started this way, more than 30 years from now, and I left this behind, for the reasons I gave. This "anti-style" might work out for a while, but sooner or later, it becomes a maintenance nightmare.
Thomas Richter is offline  
Old 02 December 2020, 15:10   #8
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
There are people that have a bit more experience in programming than you. And me, of course. These aren't my advices, actually. You can check a couple of other sources if you like, or don't trust me.
Then find a real person having more experience than me and bring him here. Or find such resources online. Else it didn't happen.


Quote:
Originally Posted by Thomas Richter View Post
Frankly, you have no clue.
I could tell you the same. This brings nothing to the discussion.


Quote:
Originally Posted by Thomas Richter View Post
I want you to comment what's worth commenting, and use clear code structure otherwise. I can only repeat: Many comments are good, code requiring many comments is bad. Your "anti-style" requires many comments, which is bad. Instead, comment non-obvious stuff.
This is only for OS code, and OS code is a small part of the overall source code.
But changing this way of coding would invade the whole program.
It's not "anti-style" at all. Just something you can't understand/accept.


Quote:
Originally Posted by Thomas Richter View Post
Include files are fine. Where is the problem with that? They modularize the code.
No, they just give a dependency hell. And being dependent of something else, is the opposite of modularizing.


Quote:
Originally Posted by Thomas Richter View Post
Code:
move.l $18(a0),a0 ;cl_super
is a bogus comment. Just write the label. Be done with it. This comment is not needed, and pointless. Use the label in first place, that's why we have include files.
I rewrote that comment to show you how wrong you were and you just ignored it. Fine.


Quote:
Originally Posted by Thomas Richter View Post
Until you write code within a team, or need to maintain code from somebody else.
This is highly unlikely for an Amiga project...
Be realistic, please. Nice theories don't work in real life.


Quote:
Originally Posted by Thomas Richter View Post
Nobody should. It doesn't really matter.
It does matter, both in speed and code size - especially when multiplied with big number. But the asm should do it for you - that's the point.
Even compilers turn peephole optimisation on. But maybe they're wrong all the way ?


Quote:
Originally Posted by Thomas Richter View Post
You look at the wrong side of the problem. The instructions aren't the problem. You loose the full picture the way you look at the problem, and that's the danger.
Repeat it as many times as you want, it will not become true.
Fact is my code works and is fast.


Quote:
Originally Posted by Thomas Richter View Post
Leave the program aside, look at it in 5 years from now. Live and learn.
Sadly for you, already done. This code has been left untouched for many years and then i returned to it. No problem found.


Quote:
Originally Posted by Thomas Richter View Post
That's all I can tell. Give the program to somebody else, ask somebody else to maintain it, or to debug it.
That can be said for every program of a significant size in the world. Maintaining other ppl's code has always been a nightmare, regardless of how it is written.
Easy to maintain is another illusion.


Quote:
Originally Posted by Thomas Richter View Post
Yes, I can say the same. I started this way, more than 30 years from now, and I left this behind, for the reasons I gave. This "anti-style" might work out for a while, but sooner or later, it becomes a maintenance nightmare.
If it is so bad, how come i never noticed ? I've been doing code for more than 35 years.
The way you started was probably quite different to mine, so it can't be compared. If you attempted that on C code, that's understandable.

OTOH, several times i've had some source code from other ppl using the way you so badly want me to use (why ?), and i clearly do not want to produce such horrors myself.
meynaf is offline  
Old 02 December 2020, 19:24   #9
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
Then find a real person having more experience than me and bring him here. Or find such resources online. Else it didn't happen.
The first time I read about this was in old ages, more than 30 years ago. For example, see "Rodnay Zaks: Programming the 6502". Anyhow, it fits to my personal experience.


In old ages, "includes" on Amiga were a bit painful, if you only had a single disk drive and little memory. But that doesn't hold anymore, for at least the last 25 years. There is no excuse not using proper tools.


Quote:
Originally Posted by meynaf View Post
I could tell you the same. This brings nothing to the discussion.
How many projects have you run, with more than one person in the team? How often have you revised your sources?


Quote:
Originally Posted by meynaf View Post
This is only for OS code, and OS code is a small part of the overall source code.
This holds for any code. Comments are not only for anyone else, but also for you. How much do you remember from your code written years ago?


Quote:
Originally Posted by meynaf View Post
But changing this way of coding would invade the whole program.
Of course a consistent readable style should be applied to the entire program.



Quote:
Originally Posted by meynaf View Post
No, they just give a dependency hell. And being dependent of something else, is the opposite of modularizing.
What's the hell about your program depending on Os includes? Or on other includes of your program? To resolve dependencies, we have Makefiles. Small investment of time, large profit.




Quote:
Originally Posted by meynaf View Post

I rewrote that comment to show you how wrong you were and you just ignored it. Fine.
Because it's just a bogus argument. Use proper tools to support you.




Quote:
Originally Posted by meynaf View Post
This is highly unlikely for an Amiga project...
Be realistic, please. Nice theories don't work in real life.
It is more than a "theory". These hints come from practicioniers, and they match my experience.




Quote:
Originally Posted by meynaf View Post

It does matter, both in speed and code size - especially when multiplied with big number. But the asm should do it for you - that's the point.
Why do you worry? We have 2020. How much "code size" is that? Actually, it is less code as you could remove pointless comments, and it is not slow if you assemble under a halfway "modern" system, leave alone under UAE, as you seem to do.




Quote:
Originally Posted by meynaf View Post

Even compilers turn peephole optimisation on. But maybe they're wrong all the way ?
So do assemblers? And yet, I do not worry too much. Fast code is made by fast algorithms.




Quote:
Originally Posted by meynaf View Post
Repeat it as many times as you want, it will not become true.
Repeat as many times as you like, you are just inexperienced, and therefore do not know better. Just try, on a large scale project. Leave alone for a couple of years, then try to maintain. Been there, done that.




Quote:
Originally Posted by meynaf View Post

Fact is my code works and is fast.
Right now. What happens if you find a bug? How do you maintain it? You are creating "write-once, read-never" code.




Quote:
Originally Posted by meynaf View Post

That can be said for every program of a significant size in the world. Maintaining other ppl's code has always been a nightmare, regardless of how it is written.
Easy to maintain is another illusion.
If you write this in your style, certainly... I've maintained other's people code, and I haven't had much trouble. But it was written in a better way than that. Actually, I haven't seen any such "anti-style" in any professional code.


Quote:
Originally Posted by meynaf View Post


If it is so bad, how come i never noticed ? I've been doing code for more than 35 years.
Never written anything of substance? Never touched code from another person? I do not know.





Quote:
Originally Posted by meynaf View Post



The way you started was probably quite different to mine, so it can't be compared. If you attempted that on C code, that's understandable.
I do not know how you started, but I started with the 6502 and, as part of that, Rodnay Zaks' work. Not that I understood back then why the man "wastes" so much time on programming style, I only appreciated that many years later. I went through a development, and appreciated lots of those advices later on. Apparently, you did not.



Quote:
Originally Posted by meynaf View Post



OTOH, several times i've had some source code from other ppl using the way you so badly want me to use (why ?), and i clearly do not want to produce such horrors myself.
You are creating the horrors, and not only by my own measures.
Thomas Richter is offline  
Old 02 December 2020, 20:10   #10
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
The first time I read about this was in old ages, more than 30 years ago. For example, see "Rodnay Zaks: Programming the 6502". Anyhow, it fits to my personal experience.
The 6502, huh ? There programs are small. Too different to validate anything regarding the 68k.


Quote:
Originally Posted by Thomas Richter View Post
In old ages, "includes" on Amiga were a bit painful, if you only had a single disk drive and little memory. But that doesn't hold anymore, for at least the last 25 years. There is no excuse not using proper tools.
I am using proper tools. Always have. We just don't agree on what proper tools are.

In C the situation would be very different, as the compiler would check if the field is in the structure or not. Or if the value is in the enum.
But in asm this doesn't work this way.
Therefore using the name isn't worth its price (except if it's declared in my own source, for my own purpose).


Quote:
Originally Posted by Thomas Richter View Post
How many projects have you run, with more than one person in the team?
Again, this is amiga asm, not big corpo project.


Quote:
Originally Posted by Thomas Richter View Post
How often have you revised your sources?
Quite often, actually. Depends on the source.


Quote:
Originally Posted by Thomas Richter View Post
This holds for any code. Comments are not only for anyone else, but also for you. How much do you remember from your code written years ago?
This is running in circles. I put enough comments so that i don't need to remember code written years ago.


Quote:
Originally Posted by Thomas Richter View Post
Of course a consistent readable style should be applied to the entire program.
Which is exactly what i'm doing.


Quote:
Originally Posted by Thomas Richter View Post
What's the hell about your program depending on Os includes? Or on other includes of your program? To resolve dependencies, we have Makefiles. Small investment of time, large profit.
And now, makefiles. This is leading nowhere.



Quote:
Originally Posted by Thomas Richter View Post
Because it's just a bogus argument. Use proper tools to support you.
This is not a valid reply.


Quote:
Originally Posted by Thomas Richter View Post
It is more than a "theory". These hints come from practicioniers, and they match my experience.
Praticioners of other languages are irrelevant here.


Quote:
Originally Posted by Thomas Richter View Post
Why do you worry? We have 2020. How much "code size" is that? Actually, it is less code as you could remove pointless comments, and it is not slow if you assemble under a halfway "modern" system, leave alone under UAE, as you seem to do.
I was speaking about the program itself, not the assembling process.


Quote:
Originally Posted by Thomas Richter View Post
So do assemblers? And yet, I do not worry too much. Fast code is made by fast algorithms.
So you say it again, but i can beat you anytime.
Should be very easy - something makes me think you're not doing a lot of asm anyway.

You can charge me of paying too much attention to micro optimisation, which you regard as a small detail.
But i can do the same for you for this whole story : the information is there, and its location (instruction or comment) is totally irrelevant.
(It would be important in a strong typed language, but here we're doing asm.)


Quote:
Originally Posted by Thomas Richter View Post
Repeat as many times as you like, you are just inexperienced, and therefore do not know better. Just try, on a large scale project. Leave alone for a couple of years, then try to maintain. Been there, done that.
Me, inexperienced ? What a garbage you've just written.


Quote:
Originally Posted by Thomas Richter View Post
Right now. What happens if you find a bug? How do you maintain it? You are creating "write-once, read-never" code.
If i find a bug, i hunt the bug. No problem.


Quote:
Originally Posted by Thomas Richter View Post
If you write this in your style, certainly... I've maintained other's people code, and I haven't had much trouble. But it was written in a better way than that. Actually, I haven't seen any such "anti-style" in any professional code.
Professional code that's easy to maintain ? I want to see that. It does not exist. As "professional code" is always made under pressure and therefore everything but easy to maintain.

Again it's not "anti-style".
In the same way it is better to do :
 jsr -$228(a6)			; OpenLibrary

than :
 jsr LVOOpenLibrary(a6)


And this, because it is more readable. Comments in asm are aligned to the right of instructions.
And the eye is there when it looks for infos.

Another benefit of using the numbers is that you end up knowing the most common ones.
And this is invaluable when debugging code you don't have the sources for.
On the Amiga i am able to enter any program and do alterations in it.
This counts a lot against the small detail of using the name in the instruction or in the comment.


Quote:
Originally Posted by Thomas Richter View Post
Never written anything of substance? Never touched code from another person? I do not know.
Yes, you do now know. That's the problem.

There are things you regard as good practices and things you regard as bad practices.
But you seem to be overgeneralizing this.
Me, i am more pragmatic.
When something is the right tool for the current job, i use it.
This is what differentiates good programmers from average or bad ones.


Quote:
Originally Posted by Thomas Richter View Post
I do not know how you started, but I started with the 6502 and, as part of that, Rodnay Zaks' work. Not that I understood back then why the man "wastes" so much time on programming style, I only appreciated that many years later. I went through a development, and appreciated lots of those advices later on. Apparently, you did not.
I started on 6502 and i do now know of this guy's work.
Anyway, 6502 and 68k are different beasts.


Quote:
Originally Posted by Thomas Richter View Post
You are creating the horrors, and not only by my own measures.
Apparently the users of my programs don't agree with this.

You just don't know how to code and you want to teach lessons to me ? Beat it.

You think you know better ? Explain. Why would it be so bad ?

The number does not change. So the code will work in the future if it works now.
(And it is what will figure in the executable anyway.)
The name does not give any info the comment does not give. Someone else reading the code will have all that is relevant.
(Actually, the number gives an information the name doesn't, it is the magnitude of the number.)
We are not dependent on external includes, which can not have bad consequences.
(Actually the opposite, for the reasons i stated.)

Frankly, i've just put a number instead of a name and this is gonna have a catastrophic impact ? This is totally irrealistic.
meynaf is offline  
Old 03 December 2020, 11:22   #11
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
The 6502, huh ? There programs are small. Too different to validate anything regarding the 68k.
And your point is? Using proper labels and includes is even more important with larger programs on the 68k. If this holds true on the 6502, it holds true on the 68K as well.



Quote:
Originally Posted by meynaf View Post
I am using proper tools. Always have. We just don't agree on what proper tools are.
It is not you agaist me. It is more like "you against the rest of the world". The rest of the world uses include files, and makefiles to structure projects.




Quote:
Originally Posted by meynaf View Post
Again, this is amiga asm, not big corpo project.
So you are sloppy? Why not do it the right way right away?



Quote:
Originally Posted by meynaf View Post
And now, makefiles. This is leading nowhere.
Makefiles are a great tool. Not only to structure code, but also generate various targets and even documenation. Seems you never used them, or never had a project that was complex enough.





Quote:
Originally Posted by meynaf View Post

Praticioners of other languages are irrelevant here.
So, in how far does it matter whether it is 6502 assembler or 68K assembler? The problem is all the same. A low level language needs better tools. Writing out label names helps.




Quote:
Originally Posted by meynaf View Post
I was speaking about the program itself, not the assembling process.
Don't you think that the program gets *larger* by introducing a lot of obvious, but useless comments if you would have used proper style in first place?




Quote:
Originally Posted by meynaf View Post
Should be very easy - something makes me think you're not doing a lot of asm anyway.
Just the reverse. Because I am doing a lot of asm, I know what works. Putting numbers instead of labels is a big no-no. Actually, I started with asm. First 6502, then 68K.




Quote:
Originally Posted by meynaf View Post
But i can do the same for you for this whole story : the information is there, and its location (instruction or comment) is totally irrelevant.
(It would be important in a strong typed language, but here we're doing asm.)
No, the label information is *not* irrelevant. It is relevant to the reader. The resulting *binary* is identical, it is just more obvious why it does what it does, plus it is easier to change.




Quote:
Originally Posted by meynaf View Post
Me, inexperienced ? What a garbage you've just written.
Well, apparently, now that you talk such a lot of "garbadge". This is not only against "my wisdom", but against the wisdom of many others.




Quote:
Originally Posted by meynaf View Post
If i find a bug, i hunt the bug. No problem.
So either your algorithms are trivial ,or you spend a lot of time with hunting down "the right numbers".




Quote:
Originally Posted by meynaf View Post
Professional code that's easy to maintain ? I want to see that.
That is the *professional* part of it, right? Not only getting things working, but also getting it done efficiently. Apparently, you haven't done that either?




Quote:
Originally Posted by meynaf View Post
In the same way it is better to do :
 jsr -$228(a6)            ; OpenLibrary

than :
 jsr LVOOpenLibrary(a6)
*puke*.


Drop the comment. Put the name right into the call.





Quote:
Originally Posted by meynaf View Post
And this, because it is more readable.
No, harder. Because there is useless information in the code such as the offset. Why should I bother about the -$228? That's useless information.








Quote:
Originally Posted by meynaf View Post
Another benefit of using the numbers is that you end up knowing the most common ones.
And why is that relevant for anything?





Quote:
Originally Posted by meynaf View Post
And this is invaluable when debugging code you don't have the sources for.
Any debugger worth its money will put in the right names for the LVOs. So it is even less useful in this case.




Quote:
Originally Posted by meynaf View Post
On the Amiga i am able to enter any program and do alterations in it.

This counts a lot against the small detail of using the name in the instruction or in the comment.
No, it just means that you confuse "reverse engineering" with "engineering".








Quote:
Originally Posted by meynaf View Post
There are things you regard as good practices and things you regard as bad practices.
But you seem to be overgeneralizing this.
That is not "me regarding something as...", but "the field in general. More than just me. Actually, almost everybody writing programs. Just take a book on assembly, read it there. Like the one I quoted. You seem like a person running on the same side of the road, and wondering why everybody else is doing wrong. Sorry, *you* are on the wrong side.




Quote:
Originally Posted by meynaf View Post
Me, i am more pragmatic.
This is exactly not pragmatic. It is "I am used to it because I started from the wrong end and cannot change my style anymore". Try to change, and you will see the advantage.




Quote:
Originally Posted by meynaf View Post
When something is the right tool for the current job, i use it.
Nope.




Quote:
Originally Posted by meynaf View Post
This is what differentiates good programmers from average or bad ones.
Yup, here we have a prime example of a bad one. You not using the tools properly.




Quote:
Originally Posted by meynaf View Post
I started on 6502 and i do now know of this guy's work.
Anyway, 6502 and 68k are different beasts.
Sure they are different from the architecture, but general style rules apply to both. So what's wrong with Zaks' advice to use "telling names" instead of numbers? Did you actually read this?




Quote:
Originally Posted by meynaf View Post
Apparently the users of my programs don't agree with this.
So, what are your programs anyhow? And how can the users tell what you did in your assembler.





Quote:
Originally Posted by meynaf View Post
You just don't know how to code and you want to teach lessons to me ? Beat it.
*Cough* I guess I did enough for this platform.




Quote:
Originally Posted by meynaf View Post
You think you know better ? Explain. Why would it be so bad ?
I already said. Harder to read, harder to maintain.





Quote:
Originally Posted by meynaf View Post
(And it is what will figure in the executable anyway.)
The name does not give any info the comment does not give.
So drop the comment and let the code speak for itself. Use the comment for things worth commenting. I already said that. Comment on *why* you are doing things, not *what* you are doing. That is exactly the advice you find in Zaks' book, in case you care.




Quote:
Originally Posted by meynaf View Post

We are not dependent on external includes, which can not have bad consequences.
So what exactly is the *bad part* about includes? If they change, you reassemble the program. Actually, the makefile does. That is the point. Assemble-time does not matter these days.






Quote:
Originally Posted by meynaf View Post
Frankly, i've just put a number instead of a name and this is gonna have a catastrophic impact ? This is totally irrealistic.
It can become catastrophic if the number is wrong, or you got confused. How do you know that the numbers are all correct? How do you extract these numbers? Why not just let the computer do that job, and get it done without errors?
Thomas Richter is offline  
Old 03 December 2020, 12:52   #12
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
And your point is? Using proper labels and includes is even more important with larger programs on the 68k. If this holds true on the 6502, it holds true on the 68K as well.
6502 is mostly very low level code. No OS includes.


Quote:
Originally Posted by Thomas Richter View Post
It is not you agaist me. It is more like "you against the rest of the world". The rest of the world uses include files, and makefiles to structure projects.
Argumentum ad populum don't work either.


Quote:
Originally Posted by Thomas Richter View Post
So you are sloppy? Why not do it the right way right away?
Not a matter or being sloppy or not. It's just that used languages are not the same.


Quote:
Originally Posted by Thomas Richter View Post
Makefiles are a great tool. Not only to structure code, but also generate various targets and even documenation. Seems you never used them, or never had a project that was complex enough.
The fun part here is "generate various targets". Again you forget we're talking about amiga asm. And for the rest we have great IDEs today that can hide all these obscure and unwieldy makefiles.


Quote:
Originally Posted by Thomas Richter View Post
So, in how far does it matter whether it is 6502 assembler or 68K assembler? The problem is all the same. A low level language needs better tools. Writing out label names helps.
Your statement which i replied to did not mention 6502.


Quote:
Originally Posted by Thomas Richter View Post
Don't you think that the program gets *larger* by introducing a lot of obvious, but useless comments if you would have used proper style in first place?
Sorry, i supposed you knew that comments don't end up in the executable file...


Quote:
Originally Posted by Thomas Richter View Post
Just the reverse. Because I am doing a lot of asm, I know what works. Putting numbers instead of labels is a big no-no. Actually, I started with asm. First 6502, then 68K.
Wasn't it you who one day told me to just use a compiler ?


Quote:
Originally Posted by Thomas Richter View Post
No, the label information is *not* irrelevant. It is relevant to the reader. The resulting *binary* is identical, it is just more obvious why it does what it does, plus it is easier to change.
It is not the label information that's irrelevant, it's its location.


Quote:
Originally Posted by Thomas Richter View Post
Well, apparently, now that you talk such a lot of "garbadge". This is not only against "my wisdom", but against the wisdom of many others.
Wake up, there are not "many others" doing 68k or 6502 asm today.


Quote:
Originally Posted by Thomas Richter View Post
So either your algorithms are trivial ,or you spend a lot of time with hunting down "the right numbers".
OS includes have nothing to do with algorithms.


Quote:
Originally Posted by Thomas Richter View Post
That is the *professional* part of it, right? Not only getting things working, but also getting it done efficiently. Apparently, you haven't done that either?
So the only reply you could write here is a personal attack...


Quote:
Originally Posted by Thomas Richter View Post
*puke*.

Drop the comment. Put the name right into the call.
I knew you wouldn't like it


Quote:
Originally Posted by Thomas Richter View Post
No, harder. Because there is useless information in the code such as the offset. Why should I bother about the -$228? That's useless information.
On the contrary, it's very useful when debugging.


Quote:
Originally Posted by Thomas Richter View Post
And why is that relevant for anything?
Try making a working source out of an executable.


Quote:
Originally Posted by Thomas Richter View Post
Any debugger worth its money will put in the right names for the LVOs. So it is even less useful in this case.
They can't always do that, and they can't do it for structure fields because they have no way to know. For consistency i use same method for both.


Quote:
Originally Posted by Thomas Richter View Post
No, it just means that you confuse "reverse engineering" with "engineering".
If there is one you can do and not the other, not my fault.


Quote:
Originally Posted by Thomas Richter View Post
That is not "me regarding something as...", but "the field in general. More than just me. Actually, almost everybody writing programs. Just take a book on assembly, read it there. Like the one I quoted. You seem like a person running on the same side of the road, and wondering why everybody else is doing wrong. Sorry, *you* are on the wrong side.
Again, argumentum ad populum.
With this kind of point of view, there would never have any innovation.


Quote:
Originally Posted by Thomas Richter View Post
This is exactly not pragmatic. It is "I am used to it because I started from the wrong end and cannot change my style anymore". Try to change, and you will see the advantage.
As i told - but you didn't read - i already tried.
And - but perhaps you didn't get it - it's only about OS includes. My own structure fields have names.


Quote:
Originally Posted by Thomas Richter View Post
Nope.
But it is true. When something is the right tool for the current job, i use it.


Quote:
Originally Posted by Thomas Richter View Post
Yup, here we have a prime example of a bad one. You not using the tools properly.
The "bad one" can beat you anytime, so you must be even poorer.


Quote:
Originally Posted by Thomas Richter View Post
Sure they are different from the architecture, but general style rules apply to both. So what's wrong with Zaks' advice to use "telling names" instead of numbers? Did you actually read this?
Why would i read it ? It's irrelevant. 6502 asm isn't using a complex OS and its includes.


Quote:
Originally Posted by Thomas Richter View Post
So, what are your programs anyhow? And how can the users tell what you did in your assembler.
If my programs were half as badly written as you suggest, they would be just full of bugs.


Quote:
Originally Posted by Thomas Richter View Post
*Cough* I guess I did enough for this platform.
Enough damage, you mean ?


Quote:
Originally Posted by Thomas Richter View Post
I already said. Harder to read, harder to maintain.
Apart that it is not in any way harder to read.
You failed to prove using OS includes improves things in any manner.


Quote:
Originally Posted by Thomas Richter View Post
So drop the comment and let the code speak for itself. Use the comment for things worth commenting. I already said that. Comment on *why* you are doing things, not *what* you are doing. That is exactly the advice you find in Zaks' book, in case you care.
I put both why and what in comments. There is no problem in doing so.


Quote:
Originally Posted by Thomas Richter View Post
So what exactly is the *bad part* about includes? If they change, you reassemble the program. Actually, the makefile does. That is the point. Assemble-time does not matter these days.
Yes if they change, you indeed reassemble the program - and discover that all of a sudden it stops working because of some incompatible change.


Quote:
Originally Posted by Thomas Richter View Post
It can become catastrophic if the number is wrong, or you got confused. How do you know that the numbers are all correct? How do you extract these numbers? Why not just let the computer do that job, and get it done without errors?
If the number is wrong, the program will simply not work and it is very easy to fix. Using the wrong number is the same as using the wrong name.

Frankly, why do you insist so much ? You have absolutely no idea of how my code is overall, you've only seen a single isolated line !

All my OS code is in a single include (MY include, not OS one). And it gets included over and over.
Programs using it should not depend on anything but this file, which in turn does not depend on anything at all.
This is what is called modularity.
Should someone rewrite all the features inside for another OS, all my code would then run on that OS.
Often the users of cpp classes on windows depend on windows.h or whatever os includes and this pisses me off.
Implementation details should not appear in interfaces.
My code is in some way platform independent.
Can you say the same about your code ?
meynaf is offline  
Old 03 December 2020, 18:33   #13
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
6502 is mostly very low level code. No OS includes.
Have you actually read the book? There, symbolic names are not used for Os includes, but for hardware addresses, which also makes a lot of sense.


Quote:
Originally Posted by meynaf View Post
Argumentum ad populum don't work either.
Oh, and you think you are the only one doing it right, and everybody else does it wrong, and you haven't tried to change your style, just as learning experience?


That's what I call "stubborness".


Quote:
Originally Posted by meynaf View Post
The fun part here is "generate various targets". Again you forget we're talking about amiga asm. And for the rest we have great IDEs today that can hide all these obscure and unwieldy makefiles.
I'm not sure why you want to hide them. Instead "work with them".



Quote:
Originally Posted by meynaf View Post
Sorry, i supposed you knew that comments don't end up in the executable file...
Symbolic names neither. Yet, they are in the source, and unlike comments, they have function.



Quote:
Originally Posted by meynaf View Post
Wasn't it you who one day told me to just use a compiler ?
That works even better, yes. At least in most cases. In the remaining cases, you need an assembler, but even that tool need to be used properly.





Quote:
Originally Posted by meynaf View Post

Wake up, there are not "many others" doing 68k or 6502 asm today.
It does not matter whether that is 6502, 68k, i386, x64 or arm. Don't tell me that these are "different languages". There is a common principle why you use telling names and not numbers.



Quote:
Originally Posted by meynaf View Post

On the contrary, it's very useful when debugging.
It's the job of the debugger to show symbolic names. It's not hard to do that with library offsets, every debugger I know does that. It's not hard to find and run a source level debugger either.


Quote:
Originally Posted by meynaf View Post

They can't always do that, and they can't do it for structure fields because they have no way to know. For consistency i use same method for both.
FOr consistency, you use the least readable version?




Quote:
Originally Posted by meynaf View Post
Again, argumentum ad populum.
With this kind of point of view, there would never have any innovation.
Actually, the innvation was to *have* symbolic names. With your approach, people would still use punch cards. The innovation is "let the computer do the job".




Quote:
Originally Posted by meynaf View Post

As i told - but you didn't read - i already tried.
And - but perhaps you didn't get it - it's only about OS includes. My own structure fields have names.
So what's so bad about Os includes and what's so great about your includes? Where is your "consistency"? Where is the "Oh, I remember in 5 years what the $18 in my code was good for?".




Quote:
Originally Posted by meynaf View Post



Apart that it is not in any way harder to read.
You failed to prove using OS includes improves things in any manner.
Yes, they do. They make sources readable and self-documenting. Not that I'm saying that for the first time.




Quote:
Originally Posted by meynaf View Post

Yes if they change, you indeed reassemble the program - and discover that all of a sudden it stops working because of some incompatible change.
It's actually quite the reverse. If I use symbolic names, the program remains working even after a change. Otherwise, I have to search for numbers, and as I don't know what the number was good for...




Quote:
Originally Posted by meynaf View Post


If the number is wrong, the program will simply not work and it is very easy to fix. Using the wrong number is the same as using the wrong name.
So, apparently, not very complex programs. Most bugs I fix are not easy to detect.


Quote:
Originally Posted by meynaf View Post



Frankly, why do you insist so much ? You have absolutely no idea of how my code is overall, you've only seen a single isolated line !
Because you are making a very fundamental error here. Yes, I know script kiddies start to write code like this, even more so on a computer system which had only a single disk drive, and 512K in 1988. But those times are long over, and it is time to adapt. It's not me who resists a change - it is you. Just try it once, and observe how the programs get better. It is a well went advice from a transition I myself went through, and I only knew afterwards what exactly I was doing wrong.




Quote:
Originally Posted by meynaf View Post




All my OS code is in a single include (MY include, not OS one). And it gets included over and over.
That looks like a sign of missing modularization. It's better to write smaller units, each with its own include file, defining only the parts that are relevant for this particular module.




Quote:
Originally Posted by meynaf View Post





Programs using it should not depend on anything but this file, which in turn does not depend on anything at all.
Dependency resolution is the matter of automatic tools. Makefiles implement them. Tools can create them.



Quote:
Originally Posted by meynaf View Post






This is what is called modularity.
No, it is the absence of modularity - exactly the opposite. You have now one big dependency, and rebuild everything just if one single detail change. It works the other way around: One include per module, so you only have to rebuild what depends on this module.


The reason for modularity is to isolate information between modules, thus to decrease the dependencies. If you just put everything into one file, you could also put all sources into one file. Same shit.



Quote:
Originally Posted by meynaf View Post







Should someone rewrite all the features inside for another OS, all my code would then run on that OS.
Hardly, because none of the offsets would be correct, and there is no abstraction.



Quote:
Originally Posted by meynaf View Post








Often the users of cpp classes on windows depend on windows.h or whatever os includes and this pisses me off.
In C++, you use "compiler firewalls" for that, hide implementations behind interfaces by a very simple idiom called "pimples". In fact, if you just have a single include file, you would not get around to have a <windows.h> included there, and thus all dependencies dragged into all modules, which is exactly wrong.


Instead, you hide the <windows.h> away, in particular includes, or possibly even in implementation files. In my projects, there is no "global depencency" on windows.h.



Quote:
Originally Posted by meynaf View Post









Implementation details should not appear in interfaces.
And that is exactly why you separate out different interfaces into different files. windows.h is as much an interface as the modules of your source. Unless you have none, of course, which is lousy structure.


Quote:
Originally Posted by meynaf View Post










My code is in some way platform independent.
Exactly not, with numbers in it instead of names.


Quote:
Originally Posted by meynaf View Post











Can you say the same about your code ?
Yes, of course I can say that. Why don't you go to my github page for some of the *public* projects. That is of course not assembly, but C++, but compiles on a varity of platforms due to autoconf. It also builds on windows, of course.
Thomas Richter is offline  
Old 03 December 2020, 20:11   #14
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
Have you actually read the book? There, symbolic names are not used for Os includes, but for hardware addresses, which also makes a lot of sense.
Then it is irrelevant. I'm speaking about OS includes, not hardware addresses.


Quote:
Originally Posted by Thomas Richter View Post
Oh, and you think you are the only one doing it right, and everybody else does it wrong, and you haven't tried to change your style, just as learning experience?
Do it the way you want, the others do it the way they want, it's not my problem. Everyone is free, and hopefully.
And as i told you several times, i actually tried the os includes. It ended up in such a mess i will nevermore do that.


Quote:
Originally Posted by Thomas Richter View Post
That's what I call "stubborness".
You seem to be quite a specialist in that area.


Quote:
Originally Posted by Thomas Richter View Post
I'm not sure why you want to hide them. Instead "work with them".
Try coding with a decent IDE, just as "learning experience".


Quote:
Originally Posted by Thomas Richter View Post
Symbolic names neither. Yet, they are in the source, and unlike comments, they have function.
They have function, but a function that can be abused like everything else. As i said, use the right tool for the task. It's not always the right tool.


Quote:
Originally Posted by Thomas Richter View Post
That works even better, yes. At least in most cases. In the remaining cases, you need an assembler, but even that tool need to be used properly.
There is a contradiction here : if that works even better, why did you tell you were doing a lot of asm ? According to what you've just written here, you should be doing mostly some compiled stuff, and asm for the few remaining cases.


Quote:
Originally Posted by Thomas Richter View Post
It does not matter whether that is 6502, 68k, i386, x64 or arm. Don't tell me that these are "different languages". There is a common principle why you use telling names and not numbers.
Still not "many others" doing it...


Quote:
Originally Posted by Thomas Richter View Post
It's the job of the debugger to show symbolic names. It's not hard to do that with library offsets, every debugger I know does that. It's not hard to find and run a source level debugger either.
Library offsets are only a small part of it. And debuggers are not immune to getting them wrong. Of course, as i already stated, they sometimes just can't do the job. What do you prefer : a solution that always work or one that sometimes fail ?


Quote:
Originally Posted by Thomas Richter View Post
FOr consistency, you use the least readable version?
Invalid argument (petitio principii). I have not in any manner agreed that it's harder to read.


Quote:
Originally Posted by Thomas Richter View Post
Actually, the innvation was to *have* symbolic names. With your approach, people would still use punch cards. The innovation is "let the computer do the job".
Invalid argument (straw man fallacy). I never told all kinds of symbolic names were useless.


Quote:
Originally Posted by Thomas Richter View Post
So what's so bad about Os includes and what's so great about your includes? Where is your "consistency"? Where is the "Oh, I remember in 5 years what the $18 in my code was good for?".
Remember : if the $18 isn't super obvious then there is a comment next to it.


Quote:
Originally Posted by Thomas Richter View Post
Yes, they do. They make sources readable and self-documenting. Not that I'm saying that for the first time.
Invalid argument (ad nauseam).


Quote:
Originally Posted by Thomas Richter View Post
It's actually quite the reverse. If I use symbolic names, the program remains working even after a change. Otherwise, I have to search for numbers, and as I don't know what the number was good for...
It can't be the reverse. If a change has to alter the number, then this breaks binary level compatibility. Same number produces same executable and it *has* to work. Same name but different number is however not guaranteed to work.


Quote:
Originally Posted by Thomas Richter View Post
So, apparently, not very complex programs. Most bugs I fix are not easy to detect.
Of course i don't write very complex programs. I keep things simple so that it is easier to debug and maintain, on the contrary to many people doing overcomplicated, bloated, and hard to debug code.


Quote:
Originally Posted by Thomas Richter View Post
Because you are making a very fundamental error here. Yes, I know script kiddies start to write code like this, even more so on a computer system which had only a single disk drive, and 512K in 1988. But those times are long over, and it is time to adapt. It's not me who resists a change - it is you. Just try it once, and observe how the programs get better. It is a well went advice from a transition I myself went through, and I only knew afterwards what exactly I was doing wrong.
I have tried it, and observed how the programs got worse.
And again, IT IS ONLY FOR OS INCLUDES.
So it has nothing "very fundamental" and isn't an error at all.


Quote:
Originally Posted by Thomas Richter View Post
That looks like a sign of missing modularization. It's better to write smaller units, each with its own include file, defining only the parts that are relevant for this particular module.
Nope. There are dependencies, like different routines using same library or device or whatever, functions calling other api functions for internal purposes, etc.
Initially some modules were in separate files and it didn't work very well.
And of course end user of the library shouldn't have to care in which module some function is located.
Frankly, as an example should i separate simple console print from file open in different modules ?


Quote:
Originally Posted by Thomas Richter View Post
Dependency resolution is the matter of automatic tools. Makefiles implement them. Tools can create them.
Dependency resolution is only needed if there is something to resolve.


Quote:
Originally Posted by Thomas Richter View Post
No, it is the absence of modularity - exactly the opposite. You have now one big dependency, and rebuild everything just if one single detail change. It works the other way around: One include per module, so you only have to rebuild what depends on this module.
And where's the problem in rebuilding everything ? You wrote yourself that building times were pretty much unimportant.
Anyway i'm not using a linker (unless i mix with C code) and building everything is a simple command - can't be simpler.


Quote:
Originally Posted by Thomas Richter View Post
The reason for modularity is to isolate information between modules, thus to decrease the dependencies. If you just put everything into one file, you could also put all sources into one file. Same shit.
And my OS abstraction layer is a single module for me. There is absolutely no problem in that !


Quote:
Originally Posted by Thomas Richter View Post
Hardly, because none of the offsets would be correct, and there is no abstraction.
What offsets ? There are no offsets visible to the end user.
AGAIN: It's just OS includes i don't use. My own structure members have names.


Quote:
Originally Posted by Thomas Richter View Post
In C++, you use "compiler firewalls" for that, hide implementations behind interfaces by a very simple idiom called "pimples". In fact, if you just have a single include file, you would not get around to have a <windows.h> included there, and thus all dependencies dragged into all modules, which is exactly wrong.

Instead, you hide the <windows.h> away, in particular includes, or possibly even in implementation files. In my projects, there is no "global depencency" on windows.h.
And thus you multiply the complexity (twice as many classes) for little benefit (and a small cost in performance).


Quote:
Originally Posted by Thomas Richter View Post
And that is exactly why you separate out different interfaces into different files. windows.h is as much an interface as the modules of your source. Unless you have none, of course, which is lousy structure.
No it is the exact opposite. With single include you do not need to care where a function is located - you have it readily available. This is a real time gain when developing.


Quote:
Originally Posted by Thomas Richter View Post
Exactly not, with numbers in it instead of names.
Did i tell you it was only for OS code that i use numbers and there is no OS code in the program itself because it is hidden away in the include ?


Quote:
Originally Posted by Thomas Richter View Post
Yes, of course I can say that. Why don't you go to my github page for some of the *public* projects. That is of course not assembly, but C++, but compiles on a varity of platforms due to autoconf. It also builds on windows, of course.
My question wasn't precise enough. I thought you understood it was all about asm, but no you didn't.
So let me retry : can you say the same about your asm code ?
meynaf is offline  
Old 03 December 2020, 21:26   #15
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by meynaf View Post
Then it is irrelevant. I'm speaking about OS includes, not hardware addresses.
Ah, where is your "consistency of unreadability"? Why does it make a difference whether a symbolic name is part of a hardware address, or part of a software structure?




Quote:
Originally Posted by meynaf View Post
Do it the way you want, the others do it the way they want, it's not my problem. Everyone is free, and hopefully.
That wasn't quite the point, was it? The point is: "Why don't you work on your style and use chances to improve it?". Nobody is perfect, and you learn something new every day.




Quote:
Originally Posted by meynaf View Post
And as i told you several times, i actually tried the os includes. It ended up in such a mess i will nevermore do that.
As in "which mess"?




Quote:
Originally Posted by meynaf View Post
Try coding with a decent IDE, just as "learning experience".
I'm also using VisualStudio at work, or GoldEd on Amiga... whatever works for the job. However, as soon as the project becomes more complex, a tool to resolve dependencies is needed. IDEs are not as flexible as makefiles. Or cmake, or whatever tool you use for that.


Quote:
Originally Posted by meynaf View Post
They have function, but a function that can be abused like everything else. As i said, use the right tool for the task. It's not always the right tool.
How a "symbolic name" can be abused is beyond me. And why a symbolic name to a hardware register is something different than a symbolic name for a structure component either.




Quote:
Originally Posted by meynaf View Post

There is a contradiction here : if that works even better, why did you tell you were doing a lot of asm ?
Whatever does the job, as always. Low level "driver code" or speed critical code is in assembly. High level control functions that are not critical are in C or any other high level language.




Quote:
Originally Posted by meynaf View Post


According to what you've just written here, you should be doing mostly some compiled stuff, and asm for the few remaining cases.
Yes, that is how it looks today, indeed. Not back then, but this was also a learning experience. It does not pay off to do everything in assembler.



Quote:
Originally Posted by meynaf View Post

Still not "many others" doing it...
Still enough people with more experience than those of you and me combined.




Quote:
Originally Posted by meynaf View Post


Library offsets are only a small part of it. And debuggers are not immune to getting them wrong.
That would surprise me - namely how to get them wrong.





Quote:
Originally Posted by meynaf View Post



Of course, as i already stated, they sometimes just can't do the job. What do you prefer : a solution that always work or one that sometimes fail ?
Why don't symbolic names always work? They do always work. Numbers fail - because they are easy to get wrong, and it is much harder to find out what exactly is wrong if you got it wrong. So what's a jsr -$c6(a6)? You don't know, unless you know what a6 is.



Quote:
Originally Posted by meynaf View Post




Invalid argument (petitio principii). I have not in any manner agreed that it's harder to read.
Names are telling. Numbers are not. OpenWindowTagList(a6) tells you what is supposed to happen. The TagID "LeftEdge" tells you wha the tag does. The numbers... mean that you have to go searching. Probably not even searching, but computing what the right number is, as the includes do not provide simple equates for them. Do you have all tags in your mind? All Os equates? That's outright silly.




Quote:
Originally Posted by meynaf View Post

Invalid argument (straw man fallacy). I never told all kinds of symbolic names were useless.





So where's the difference between cl_Super(a0) and ciaapra(a0)?




Quote:
Originally Posted by meynaf View Post
Remember : if the $18 isn't super obvious then there is a comment next to it.
And where is the difference just putting the symbol right there without the comment?



Quote:
Originally Posted by meynaf View Post


It can't be the reverse. If a change has to alter the number, then this breaks binary level compatibility. Same number produces same executable and it *has* to work. Same name but different number is however not guaranteed to work.
I beg your pardon? The equates are there to help the programmer, to generate code that is readable and self-documenting. Use the offer. Or just try once and share your experience.





Quote:
Originally Posted by meynaf View Post
Of course i don't write very complex programs. I keep things simple so that it is easier to debug and maintain, on the contrary to many people doing overcomplicated, bloated, and hard to debug code.
Well, then as I assumed, you lack quite some experience with larger projects. That explains the problem.



Quote:
Originally Posted by meynaf View Post

I have tried it, and observed how the programs got worse.
In which way?


Quote:
Originally Posted by meynaf View Post
And again, IT IS ONLY FOR OS INCLUDES.
So what makes Os includes special compared to your includes? What makes hardware structure different to software structure?


Quote:
Originally Posted by meynaf View Post

Nope. There are dependencies, like different routines using same library or device or whatever, functions calling other api functions for internal purposes, etc.
Initially some modules were in separate files and it didn't work very well.
In which way didn't it work? Maybe you got the concepts wrong? It works nicely here.




Quote:
Originally Posted by meynaf View Post
And of course end user of the library shouldn't have to care in which module some function is located.
If you develop a library, you would typically have multple includes for them, of course, depending on which feature of the library is used. Just to name some, there is <exec/memory.h>, <exec/ports.h>, <exec/nodes.h>.... all is nicely separated out, so you don't need to include everything. That's modularization.


Quote:
Originally Posted by meynaf View Post

Frankly, as an example should i separate simple console print from file open in different modules ?
I'm not sure what you are saying. You are talking about a trivial "hello world?" There is no module there, but I'm not talking about such type of toy programs. I'm talking about "real stuff".


Quote:
Originally Posted by meynaf View Post


And where's the problem in rebuilding everything ? You wrote yourself that building times were pretty much unimportant.
That depends on the size of the program, of course.


Quote:
Originally Posted by meynaf View Post

Anyway i'm not using a linker (unless i mix with C code) and building everything is a simple command - can't be simpler.
If the program is "short enough", this might work for you. If it is "long enough", it does not.


Quote:
Originally Posted by meynaf View Post

And my OS abstraction layer is a single module for me. There is absolutely no problem in that !
There are many problems with that. The Os is not a single layer - there are multiple modules that are build on top of each other, i.e. there is a structure behind this.




Quote:
Originally Posted by meynaf View Post


What offsets ? There are no offsets visible to the end user.
Then, why dou you write comments? The end user doesn't see comments either?


Quote:
Originally Posted by meynaf View Post
AGAIN: It's just OS includes i don't use. My own structure members have names.
So what's the difference between your structures and the Os structures? You are not consistent then?


Quote:
Originally Posted by meynaf View Post
And thus you multiply the complexity (twice as many classes) for little benefit (and a small cost in performance).
Pimples reduce complexity as "compiler firewall".




Quote:
Originally Posted by meynaf View Post
No it is the exact opposite. With single include you do not need to care where a function is located - you have it readily available. This is a real time gain when developing.
And you polute the name space, and need to rebuild everything once you change something. Apparently, you seem to believe includes only deliver function names - typically, they deliver very little function names in my case. They deliver a lot of the structure.




Quote:
Originally Posted by meynaf View Post
Did i tell you it was only for OS code that i use numbers and there is no OS code in the program itself because it is hidden away in the include ?
And again, why is there a difference?




Quote:
Originally Posted by meynaf View Post

My question wasn't precise enough. I thought you understood it was all about asm, but no you didn't.
So let me retry : can you say the same about your asm code ?
Asm code is machine specific, naturally. I cannot write assembler that runs on 68k and x64 simultaneously. Quite apparent.
Thomas Richter is offline  
Old 04 December 2020, 10:12   #16
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
Ah, where is your "consistency of unreadability"?
Again it's not unreadable. Stop that nonsense NOW.
You want a big proof sent to your face, really ?


Quote:
Originally Posted by Thomas Richter View Post
Why does it make a difference whether a symbolic name is part of a hardware address, or part of a software structure?
Well, thinking again about it, it indeed does not make much of a difference. In both cases, the number is actually better.
Every coder reasonably advanced knows what $dff180 or $dff09a are.

Frankly, do you really want me to include hardware/custom.i and hardware/intbits.i and write this horror instead :
 move.w #INTB_INTEN,intena



Quote:
Originally Posted by Thomas Richter View Post
That wasn't quite the point, was it? The point is: "Why don't you work on your style and use chances to improve it?". Nobody is perfect, and you learn something new every day.
Except that what you suggest isn't an improvement, it is a regression.
Believe me, my coding style is quite different now than it was many years ago.


Quote:
Originally Posted by Thomas Richter View Post
As in "which mess"?
I think you know it, you're doing it every day. Think of me next time you have an assembly error.


Quote:
Originally Posted by Thomas Richter View Post
I'm also using VisualStudio at work, or GoldEd on Amiga... whatever works for the job. However, as soon as the project becomes more complex, a tool to resolve dependencies is needed. IDEs are not as flexible as makefiles. Or cmake, or whatever tool you use for that.
Dependency hell, huh ? Hopefully my code is immune to that.


Quote:
Originally Posted by Thomas Richter View Post
How a "symbolic name" can be abused is beyond me. And why a symbolic name to a hardware register is something different than a symbolic name for a structure component either.
It can be abused, because the number gives direct information whereas the name gives indirect information. This indirection has a cost in readability. Wanna have an example maybe ?


Quote:
Originally Posted by Thomas Richter View Post
Whatever does the job, as always. Low level "driver code" or speed critical code is in assembly. High level control functions that are not critical are in C or any other high level language.
Yes but - that's my point - if you do asm only for low level / speed critical code, you're clearly doing a lot less asm than i do. So i have better experience than you have.


Quote:
Originally Posted by Thomas Richter View Post
Still enough people with more experience than those of you and me combined.

Added together we have something like 60-70 years of experience.
Really, find someone who has more.


Quote:
Originally Posted by Thomas Richter View Post
That would surprise me - namely how to get them wrong.
Oh, it's very easy. It's when the debugger can't know the library base.


Quote:
Originally Posted by Thomas Richter View Post
Why don't symbolic names always work? They do always work. Numbers fail - because they are easy to get wrong, and it is much harder to find out what exactly is wrong if you got it wrong. So what's a jsr -$c6(a6)? You don't know, unless you know what a6 is.
But you *have* to know what a6 is in all cases, otherwise you can't be sure your jsr LVOAllocMem(a6) will call the right function...


Quote:
Originally Posted by Thomas Richter View Post
Names are telling. Numbers are not. OpenWindowTagList(a6) tells you what is supposed to happen. The TagID "LeftEdge" tells you wha the tag does. The numbers... mean that you have to go searching. Probably not even searching, but computing what the right number is, as the includes do not provide simple equates for them. Do you have all tags in your mind? All Os equates? That's outright silly.
I don't care, really. When using a tag for the first time, i need to read the doc about it. When doing that, i also grab its number - it's the docs that are wrong in not providing it directly, not me.
Then, it's just a matter of copy-paste.
It's not as if there were OS tag values scattered all over the place in my programs.

Now consider static initialization of a gadget structure with DC directives.
There you can't use your beloved names anymore, you have to know the structure layout - i.e. the numbers.


Quote:
Originally Posted by Thomas Richter View Post
So where's the difference between cl_Super(a0) and ciaapra(a0)?
There is none. Both make an assumption about a0 that's not guaranteed to be held.


Quote:
Originally Posted by Thomas Richter View Post
And where is the difference just putting the symbol right there without the comment?
The number does not require to include anything, it's independent and guaranteed to assemble fine even if the code is built on a machine with a different OS include version (and even without any OS includes installed at all).


Quote:
Originally Posted by Thomas Richter View Post
I beg your pardon? The equates are there to help the programmer, to generate code that is readable and self-documenting. Use the offer. Or just try once and share your experience.
You don't know the difference between binary level and object level compatitilities, do you ?


Quote:
Originally Posted by Thomas Richter View Post
Well, then as I assumed, you lack quite some experience with larger projects. That explains the problem.
You are confusing the size, the complexity, and the feature level.


Quote:
Originally Posted by Thomas Richter View Post
In which way?
I don't remember all the gruesome details. Includes not found, version mismatch, no easy way to find in which include something was located, etc.

Anyway, why should i prove anything ?
After all, if you advocate a change, it's yours to provide the proof (else it is reversing the charge of the proof).
So please speak about in which ways (with concrete and detailed examples) your experience with numbers got wrong. That would be more useful.


Quote:
Originally Posted by Thomas Richter View Post
So what makes Os includes special compared to your includes?
I have an include at the top to define all the relevant macros, and another in the bottom (after the code) to do the actual implementation - it needs to know which functions are called in order to not put everything in.
I don't need to include anything else. Always same name.

OTOH, OS includes are many files scattered in many dirs. When using a function i like having it readily available and there they aren't.


Quote:
Originally Posted by Thomas Richter View Post
What makes hardware structure different to software structure?
Not much indeed.


Quote:
Originally Posted by Thomas Richter View Post
In which way didn't it work? Maybe you got the concepts wrong? It works nicely here.
Have you made a complete OS encapsulation library ?
If not, you can not know why it can't work nicely.


Quote:
Originally Posted by Thomas Richter View Post
If you develop a library, you would typically have multple includes for them, of course, depending on which feature of the library is used. Just to name some, there is <exec/memory.h>, <exec/ports.h>, <exec/nodes.h>.... all is nicely separated out, so you don't need to include everything. That's modularization.
Modularization yes but not a very good encapsulation !


Quote:
Originally Posted by Thomas Richter View Post
I'm not sure what you are saying. You are talking about a trivial "hello world?" There is no module there, but I'm not talking about such type of toy programs. I'm talking about "real stuff".
It was just a simple example ! (and you refused to provide an answer, btw)
It could have been : should i separate video (frame buffer) handing from GUI parts ?


Quote:
Originally Posted by Thomas Richter View Post
That depends on the size of the program, of course.
PhxAss on Winuae JIT can assemble a 1MB program in less than 1 second. I think i'm covered


Quote:
Originally Posted by Thomas Richter View Post
If the program is "short enough", this might work for you. If it is "long enough", it does not.
Unless you really love producing bloatware, not all programs are "long enough". Actually, most code is "short enough". I can write a small tool for whatever purpose i need in a matter of minutes or hours.
All that to say that "short enough" is actually the most common case, and i always optimise for the most common case. Treating all programs as it they were very big is a bad idea, really.

Back in '98 or so i had to split a big program and use a linker because the A1200's 2mb weren't enough to assemble it. Then i got 030 with 16mb. Then i could merge it again. Phew.
But i am able to do that again if needed. It is not a problem. However it is rarely needed, if ever, nowadays.


Quote:
Originally Posted by Thomas Richter View Post
There are many problems with that. The Os is not a single layer - there are multiple modules that are build on top of each other, i.e. there is a structure behind this.
The underlying OS architecture is none of my business, really. The goal is precisely to encapsulate it !
These modules will be different if you consider porting the code to another architecture.
Same code could run on Atari ST or Mac OS 68k, maybe even Megadrive, with no change at all - only the includes would be different.
And by converting the asm code in some automatic way (with a small vm), then it could potentially work on *any* architecture.


Quote:
Originally Posted by Thomas Richter View Post
Then, why dou you write comments? The end user doesn't see comments either?
In my post "end user" was the program using the includes. Sorry if it wasn't clear. And indeed comments in said includes are pertaining to implementation details and don't need to be seen when just using them.


Quote:
Originally Posted by Thomas Richter View Post
So what's the difference between your structures and the Os structures? You are not consistent then?
My structures are located at the start of current source file. I don't have to hunt in several includes to find them. They also change all the time as fields get added or (re)moved, whereas OS includes provide something that does not evolve in totally incompatible ways.
In some way, OS structures definitions are "const" where mine aren't.
Call it an inconsistency if you like. If using the right tool for the job is being inconsistent.


Quote:
Originally Posted by Thomas Richter View Post
Pimples reduce complexity as "compiler firewall".
To me they just look like a hack to circumvent one of the programming language's shortcomings.
And they won't work for function parameters - you still have to abstract handles to void* and lose type checking in the process.


Quote:
Originally Posted by Thomas Richter View Post
And you polute the name space,
How can you be so wrong here ? All my names have prefix and i never had any conflict. And you will now pretend that OS includes don't pollute the name space ? This is nonsense. They do pollute it quite a lot and it is even one of the reasons for me not using them !


Quote:
Originally Posted by Thomas Richter View Post
and need to rebuild everything once you change something.
Unclear. What is "everything" and what is "something" ?
I don't change the OS encapsulation code all the time.
Programs using it do not need to be reassembled if new features get added in it.


Quote:
Originally Posted by Thomas Richter View Post
Apparently, you seem to believe includes only deliver function names - typically, they deliver very little function names in my case. They deliver a lot of the structure.
So you have your structure specified twice : once in a header file, once in the implementation. A bad idea, really.
Header files are for interfaces, not for structure.


Quote:
Originally Posted by Thomas Richter View Post
And again, why is there a difference?
It only touches a small part of overall programs, i.e. the part that uses the host OS directly.
So even if i admitted it was a messy way of doing, it would only affect a single source, actually, not the whole programs. But you here clearly assume it does.


Quote:
Originally Posted by Thomas Richter View Post
Asm code is machine specific, naturally. I cannot write assembler that runs on 68k and x64 simultaneously. Quite apparent.
But you can write assembler that will run on Atari ST, Amiga, MacOS 68k...
The only trick is to group everything OS/hardware specific to a small part that will be rewritten for each.
Besides, with a relatively simple cpu translation layer it would also work on x64, aarch64, or whatever.
meynaf is offline  
Old 04 December 2020, 15:34   #17
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 44
Posts: 3,216
While I prefer OS includes too, I absolutely fail to see how this
Code:
move.l cl_Super(a0),a0 ;do whatever
is in any way, shape or form more readable or maintainable than this.
Code:
move.l $18(a0),a0 ;do whatever (cl_Super)
Makes absolutely no difference.
Thorham is offline  
Old 04 December 2020, 16:16   #18
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,043
Quote:
Originally Posted by Thorham View Post
While I prefer OS includes too, I absolutely fail to see how this
Code:
move.l cl_Super(a0),a0 ;do whatever
is in any way, shape or form more readable or maintainable than this.
Code:
move.l $18(a0),a0 ;do whatever (cl_Super)
Makes absolutely no difference.

Yes, of course there is a difference. The first one is guaranteed to be correct. The second one could be the suorce of a subtile error. Do you actually know whether $18 is the right offset? If so, how? And if not, how would you find out without debugging?
Thomas Richter is offline  
Old 04 December 2020, 16:23   #19
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,227
Quote:
Originally Posted by Thomas Richter View Post
Yes, of course there is a difference. The first one is guaranteed to be correct. The second one could be the suorce of a subtile error. Do you actually know whether $18 is the right offset? If so, how? And if not, how would you find out without debugging?
No the first one isn't guaranteed to be correct. It could be a member of another structure, or just every possible define.
meynaf is offline  
Old 04 December 2020, 16:27   #20
Ernst Blofeld
<optimized out>

Ernst Blofeld's Avatar
 
Join Date: Sep 2020
Location: <optimized out>
Posts: 304
Thomas,

Meynaf is wrong. He know's he's wrong. He's just arguing with you for entertainment. While there's nothing wrong with that, you could both choose something more worthwhile to argue about.

Regards,

The rest of the internet.
Ernst Blofeld is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
DoSuperMethodA without amiga.lib meynaf Coders. System 26 06 December 2020 12:44
Wanted: P96 emulation.lib, rtg.lib autodocs, FD/LVO files PeterK Coders. System 6 01 January 2015 19:59
DoSuperMethodA mritter0 Coders. C/C++ 3 08 December 2014 06:56
Cinemaware posts Amiga games for download Mangar Amiga scene 20 28 September 2004 04:47
"New Posts" does not show posts to News section? fiath project.EAB 5 27 September 2004 13:23

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.16717 seconds with 15 queries