DoSuperMethodA without amiga.lib side posts

[Thomas Richter]

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.

[meynaf]

Originally Posted by Thomas Richter

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.

[Thomas Richter]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

[meynaf]

Originally Posted by Thomas Richter

Do you think you will keep comments updated all the way? Comments on code are good, but code requiring comments is bad. Just use the tools of the language to make things obvious, then you can keep the comments for things that are worth commenting.

Aside of all this being completely OT, these comments do not need to be "updated". They are here, period. It's not as if these values could change overnight !
If code requiring comments is bad, then all code in the world is bad.
If you think some code is obvious and is not worth commenting, think twice. Chances are good you are making a mistake.

A comment that is there but not very useful isn't a problem. A comment that's NOT here where there should be one is a lot more problematic.

Originally Posted by Thomas Richter

The source level debugging information is rather generic, it would surprise me if other assemblers cannot create it as well.

Well, perhaps they can. And perhaps i don't want to bloat the thing with this kind of irrelevant info.
Besides, the source could be anywhere, including in an editor that's not even running on the Amiga (i.e. opened in np++ while the code is in debug in winuae - in windowed mode i can see both together). Altering the source as mistakes are found make said source obsolete in regard to any source level debugging.

Originally Posted by Thomas Richter

I don't know what you need, but DevPac is a rather powerful tool.

No support for basereg. Optimisation level of branches very poor. Very slow to assemble. Etc, etc.

I need a debugger that can trace into a function that's in input.device context (like the hook of a class). For obvious reasons Devpac can't do this.
And i'm not talking about OS killing programs...

Note that even though it's not my case, many coders use winuae's built-in debug facilities, of course without any source level possibilities.

Originally Posted by Thomas Richter

Let it be what it is, what you do here is "shooting yourself into the foot".

Nope. Remember this is asm ; in C i would indeed use the names.

There is nothing wrong in using the numbers in asm programs, really. It has always worked fine and always will. It's a magnitude more lean and mean.
And of course, when it comes to resourcing (= disassemble programs and reassemble them), knowing the (most common) numbers helps a lot.

Consider this : as long as you use a good enough assembler, my code can readily assemble on any setup. No path in sources, no incdir mess, no special config required, no version conflicts, no need to have anything particular installed.

Btw what is your motivation here ? Warning me is something, insisting is something else.

[Thomas Richter]

Originally Posted by meynaf

If code requiring comments is bad, then all code in the world is bad.

Sorry, this is so wrong. Maybe look into some books on good programming practise if you don't believe me. Maybe you're not working long enough in the field, maybe your programs are too short or too simple, but thrust me:


Comments are good. Programs requiring comments are bad.


Code should be to a major degree "self-documenting", so something like

move.l $18(a0),a0 ;cl_Super

is bad, because there is a self-documenting alternative:

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:

; 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,

addq.l #1,d0 ;increment d0

is *bullshit*. It is obvious that this instruction increments d0. Instead, comment *why* you are doing this:

addq.l #1,d0 ;advance to the next index in the list

as an example.


These principles aren't new, aren't mine...

Originally Posted by meynaf

Besides, the source could be anywhere, including in an editor that's not even running on the Amiga (i.e. opened in np++ while the code is in debug in winuae - in windowed mode i can see both together). Altering the source as mistakes are found make said source obsolete in regard to any source level debugging.

Use better tools. Seriously. The WinUAE debugger is... sorry Tony... not usable. It is a "last resort", but not a tool for program development. Use a debugger that works and offers the right tools. Source level debugging, I named it already.

Originally Posted by meynaf

No support for basereg. Optimisation level of branches very poor. Very slow to assemble. Etc, etc.

Low-level optimizations: Don't waste your time with that. Not worth it. Algorithms make programs fast. Not micro-optimizations. "basereg" you can certainly do with DevPac - you just have to organize your "data section" accordingly. I don't see that the assembly speed is in any sense critical at all.

Originally Posted by meynaf

I need a debugger that can trace into a function that's in input.device context (like the hook of a class). For obvious reasons Devpac can't do this.

MonAm cannot. But it is rarely needed. I'm using COP for this, but this is a "last resort", and not something I would design my "coding style" for - this is the wrong way around.

Originally Posted by meynaf

And i'm not talking about OS killing programs...

Don't kill the Os. The Os is your friend, not your enemy.

Originally Posted by meynaf

Note that even though it's not my case, many coders use winuae's built-in debug facilities, of course without any source level possibilities.

A lot of people do crazy stuff. Again, the way how I see it, it is not a debugger for development. For me, this sounds like masochism.

Originally Posted by meynaf

There is nothing wrong in using the numbers in asm programs, really.

There is a lot wrong with that. Just unreadable, unmaintainable programs, and I'm doing this for a long time.

Originally Posted by meynaf

It has always worked fine and always will. It's a magnitude more lean and mean.

Nope. Changing your style is hard, but the change is worth it. Just try.

Originally Posted by meynaf

And of course, when it comes to resourcing (= disassemble programs and reassemble them), knowing the (most common) numbers helps a lot.

I was talking about development. Not "cracking" or "resourcing".

Originally Posted by meynaf

Consider this : as long as you use a good enough assembler, my code can readily assemble on any setup.

And got lost in details, and hours of debugging. Not my type of fun.

Originally Posted by meynaf

No path in sources, no incdir mess, no special config required, no version conflicts, no need to have anything particular installed.

include and incdir are not a mess. They are development necessities for non-trivial programs. Proper includes, proper makefiles, and a linker phase. As soon as a program becomes large enough, it becomes necessary to structure your work. These tools help to structure your work.


It seems, at the start, as if this is more work, but the invested time pays of very soon, you just have to start right from the beginning.


Btw what is your motivation here ? Warning me is something, insisting is something else.[/QUOTE]

[meynaf]

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 ??

Originally Posted by Thomas Richter

Code should be to a major degree "self-documenting", so something like

move.l $18(a0),a0 ;cl_Super

is bad, because there is a self-documenting alternative:

move.l cl_Super(a0),a0

You want to go this way ? You won't win. What about :

 move.l $18(a0),a0       ; access to parent class pointer (cl_Super)

"self documented" is an illusion.

Originally Posted by Thomas Richter

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:

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

In the same vain,

addq.l #1,d0 ;increment d0

is *bullshit*. It is obvious that this instruction increments d0. Instead, comment *why* you are doing this:

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

I don't see that the assembly speed is in any sense critical at all.

But with very large programs it is.

Originally Posted by Thomas Richter

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 !

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

And got lost in details, and hours of debugging. Not my type of fun.

Frankly, you're making a mountain out of a molehill.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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 ?

[Thomas Richter]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

This is exactly the reason why the assembler should compute the size of branches, not me.

Nobody should. It doesn't really matter.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

Frankly, you have no clue.

I could tell you the same. This brings nothing to the discussion.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

[Thomas Richter]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

Originally Posted by meynaf

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?

Originally Posted by meynaf

But changing this way of coding would invade the whole program.

Of course a consistent readable style should be applied to the entire program.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

How many projects have you run, with more than one person in the team?

Again, this is amiga asm, not big corpo project.

Originally Posted by Thomas Richter

How often have you revised your sources?

Quite often, actually. Depends on the source.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

Of course a consistent readable style should be applied to the entire program.

Which is exactly what i'm doing.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

Because it's just a bogus argument. Use proper tools to support you.

This is not a valid reply.

Originally Posted by Thomas Richter

It is more than a "theory". These hints come from practicioniers, and they match my experience.

Praticioners of other languages are irrelevant here.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

[Thomas Richter]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

Again, this is amiga asm, not big corpo project.

So you are sloppy? Why not do it the right way right away?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

Another benefit of using the numbers is that you end up knowing the most common ones.

And why is that relevant for anything?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

When something is the right tool for the current job, i use it.

Nope.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

I already said. Harder to read, harder to maintain.

Originally Posted by meynaf

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

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

[meynaf]

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

*puke*.

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

I knew you wouldn't like it

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

And why is that relevant for anything?

Try making a working source out of an executable.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

Nope.

But it is true. When something is the right tool for the current job, i use it.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

*Cough* I guess I did enough for this platform.

Enough damage, you mean ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 ?

[Thomas Richter]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

Originally Posted by meynaf

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

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

Originally Posted by meynaf

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

Originally Posted by meynaf

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?".

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

My code is in some way platform independent.

Exactly not, with numbers in it instead of names.

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

That's what I call "stubborness".

You seem to be quite a specialist in that area.

Originally Posted by Thomas Richter

I'm not sure why you want to hide them. Instead "work with them".

Try coding with a decent IDE, just as "learning experience".

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

Yes, they do. They make sources readable and self-documenting. Not that I'm saying that for the first time.

Invalid argument (ad nauseam).

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 !

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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 ?

[Thomas Richter]

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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"?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

Still not "many others" doing it...

Still enough people with more experience than those of you and me combined.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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)?

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

I have tried it, and observed how the programs got worse.

In which way?

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

Originally Posted by meynaf

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?

Originally Posted by meynaf

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

Originally Posted by meynaf

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.

Originally Posted by meynaf

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?

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

What makes hardware structure different to software structure?

Not much indeed.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 !

Originally Posted by Thomas Richter

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 ?

Originally Posted by Thomas Richter

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

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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 !

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

Originally Posted by Thomas Richter

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.

[Thorham]

While I prefer OS includes too, I absolutely fail to see how this

move.l cl_Super(a0),a0 ;do whatever

is in any way, shape or form more readable or maintainable than this.

move.l $18(a0),a0 ;do whatever (cl_Super)

Makes absolutely no difference.

[Thomas Richter]

Originally Posted by Thorham

While I prefer OS includes too, I absolutely fail to see how this

move.l cl_Super(a0),a0 ;do whatever

is in any way, shape or form more readable or maintainable than this.

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?

[meynaf]

Originally Posted by Thomas Richter

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.

[Ernst Blofeld]

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.