DoSuperMethodA without amiga.lib side posts

[Thomas Richter]

Originally Posted by Thorham

Yes, because I looked it up, which I don't like doing because I find it a pain, but it's still correct.

Maybe it is correct if you maybe looked it up right. The chance that you get it wrong may be small, but given that the program is large, the probabilty that at least one number is wrong becomes relevant. On the other hand, the chance that the machine gets it wrong is 0%, no matter how often you include a symbol.



The assember or compiler can make the "look the offsets up" much more reliable, actually 100% reliable, and a lot less error-prone. Let the machine do the job for you. It will warn you on typos. Nobody wil warn you if the numbers are wrong.

Originally Posted by Thorham

You can just double check those numbers. Not a big deal, just annoying.

That is not very practical for any reasonably sized program.

Originally Posted by Thorham

Look, I get where you're coming from and I don't think you're wrong, but meynaf isn't either.

That looks pretty wrong to me. It is against any professional advice I have seen, and also against my own experience on the matter. I openly admit having done the same mistake, but at least I know I did a mistake, and I adjust my style to my findings.

Originally Posted by Thorham

The advantage of his approach is clearly that he limits dependencies to a single file which itself doesn't have any dependencies what so ever. It's not an approach I like, but I can certainly appreciate the idea behind it and don't see what's so bad about it.

That is a different matter - it is not "completely wrong" compared to replacing symbolic names by numbers, but it is still a problem with modularization.


Generally, the include file should define the interface of the corresponding source file, and whenever this interface is needed, this file should be included. Combine that with a build environment such as "make", and you get automatic dependency resolution, and automatic re-assembling/re-compilation whenever you change the interface.


Thus, the reason why that is a good advice is quite obvious to me.


My experience at maintaining foreign code says pretty much the same. I remember the problems I had with ARexx for 3.1.4, which is essentially "one big blob of code", lacking any interfaces. One file, consisting of just a long list of "includes". Thus, if you change some source, you do not know where the interface is defined (usually the .i file) or how to check whether a change has any impact otherwise (usually, check where the .i file is included - easy to find out).

[meynaf]

And you didn't see it !

I posted some code here that was intentionnally wrong, just to show you how easy it is to make a mistake with names.
Do you remember my

move.w #INTB_INTEN,intena

?
Yes, that thing you missed in post #21.

The above code doesn't work, and for two reasons.
When converted to numbers, it gives :

 move.w #14,$9a

Of course should be :

 move.w #$4000,$dff09a

With numbers, no possible confusion. With names it is more difficult to spot.
So much for your "more readable".

Frankly, several years later, do you still remember INTB_INTEN is the bit and INTF_INTEN is the mask ?

Yes this is called a proof.
You pretend the machine will warn you on typos but here it does not (a compiler might, but this is about asm).

[Thorham]

Originally Posted by Thomas Richter

That is not very practical for any reasonably sized program.

We're talking about meynaf's OS framework. I actually have a version of that which he uses in his image viewer. This is framework just under 5000 lines, including empty lines and comment lines. Not exactly large. This code contains all the OS related code. We're not talking about a complete program with OS code spread all over the place. If that was the case it would be awful indeed.

Originally Posted by Thomas Richter

it is still a problem with modularization

Not in this case. 5000 lines of code you can easily include anywhere is quite convenient and easy to use.

Originally Posted by Thomas Richter

Generally, the include file should define the interface of the corresponding source file, and whenever this interface is needed, this file should be included. Combine that with a build environment such as "make", and you get automatic dependency resolution, and automatic re-assembling/re-compilation whenever you change the interface.

And with this framework you include two files that have no external dependencies at all and you're done. It doesn't get any easier than that.

[Ernst Blofeld]

Not wanting to talk for Thomas, but:

Originally Posted by meynaf

And you didn't see it !

I posted some code here that was intentionnally wrong, just to show you how easy it is to make a mistake with names.

You also pointed it out in that post by calling it a "horror", so it was never hidden from anyone.

Frankly, several years later, do you still remember INTB_INTEN is the bit and INTF_INTEN is the mask ?

B for bit, F for field? Easier than numbers.

[Thomas Richter]

Originally Posted by Thorham

And with this framework you include two files that have no external dependencies at all and you're done. It doesn't get any easier than that.

I afraid you do not understand what "modularization" means or is about. Let me explain again: It helps to split a big problem the program is supposed to solve into sub-problems. Each sub-problem gets a module, and a separate source file, plus a separate include file. You keep the interfaces between modules small, so you reduce the dependencies. Thus, if you work on a sub-problem, you do not need to change everything - provided you designed your interfaces well. "Well" as in "small" and "by hiding unnecessary information".



Everything a module needs to know about other modules is in the include files from the other modules.


Thus, if modulea.asm includes moduleb.i and modulec.i, you know what the depencies are.


With one big blob - you do not have that information. You need to search.


Also, the build phase profits from that. If you change moduleb.asm, without changing its interface, only moduleb needs to be rebuild, and nothing else. This is typically much less than the whole program.


If you change the interface, only modules including moduleb.i have to be rebuild, and that is also less than the full program.

[Ernst Blofeld]

Originally Posted by Thorham

5000 lines of code you can easily include anywhere

Just like we did in the 80s.

[meynaf]

Originally Posted by Ernst Blofeld

You also pointed it out in that post by calling it a "horror", so it was never hidden from anyone.

Yes but considering the point of view i'm supposed to defend here, you could have interpreted this as me just mocking the use of the names.

And yet nobody has spotted the mere fact it was just plain wrong and not working.
Because it was far from being as obvious as with the numbers.

Originally Posted by Ernst Blofeld

B for bit, F for field? Easier than numbers.

Single letter often escapes the view. Confusion is so easy. But large number vs small number do not escape.
And don't tell me you will always remember that as clearly as it is now.

Originally Posted by Thomas Richter

I afraid you do not understand what "modularization" means or is about. Let me explain again: It helps to split a big problem the program is supposed to solve into sub-problems. Each sub-problem gets a module, and a separate source file, plus a separate include file. You keep the interfaces between modules small, so you reduce the dependencies. Thus, if you work on a sub-problem, you do not need to change everything - provided you designed your interfaces well. "Well" as in "small" and "by hiding unnecessary information".

Everything a module needs to know about other modules is in the include files from the other modules.

Thus, if modulea.asm includes moduleb.i and modulec.i, you know what the depencies are.

With one big blob - you do not have that information. You need to search.

Also, the build phase profits from that. If you change moduleb.asm, without changing its interface, only moduleb needs to be rebuild, and nothing else. This is typically much less than the whole program.

If you change the interface, only modules including moduleb.i have to be rebuild, and that is also less than the full program.

This is all theory. Thorham has seen the actual code, you haven't.


But now let's imagine i suddenly decide to use names everywhere, as STRONGLY suggested.
What would the consequences be ?
First, if the includes are made directly in the include file, it will result in huge namespace pollution.
F.e. just include definitions for custom chip registers and see all your instances of "color" label fail miserably. Ouch.
To avoid this, i must use a linker and thus put all the code in a separate source - actually several, as also "suggested". And assemble that separately.
That means object code must in some way be available for all programs using the includes. Simple INCPATH in asm's config will no longer be enough.
So either a program is built with several commands, or it uses some script or makefile.
And then a very nice (ahem) absolute path has to be added to the build process or it won't find the lib.
Now if i just want to write some small test program for whatever purpose, new code setup requires creating several files instead of just one.
And it's the end of me being able to create new small program in less than a minute.
The code within the library itself is no longer as lean and mean as before, as linkers can't directly optimise code (contrary to if/endc in the source).
Provided this is even possible : the library does a lot of magic like routine changes depending on cpu type, automatic error handling and resource tracking.
It would require using complicated, unwieldy things such as ctors and dtors, that i suppose not every linker will support.

And all that for the sake of having names in a source file i don't even touch often. It's just plain crazy.

[Thomas Richter]

Originally Posted by meynaf

This is all theory. Thorham has seen the actual code, you haven't.

I already know enough by the number of lines. That is too much, and too long. Split things up into smaller files. Of course, for assembly, files grow larger, but that still sounds too much by a factor of two at least.

Originally Posted by meynaf

But now let's imagine i suddenly decide to use names everywhere, as STRONGLY suggested.
What would the consequences be ?

A worthwhile investion of time. Readable code.

Originally Posted by meynaf

First, if the includes are made directly in the include file, it will result in huge namespace pollution.

Assembly doesn't have namespaces. Well, at least not the regular assemblers. It is common to use three-letter or two-letter structure acronyms to identify where the name belongs. Worked quite well for me.


Also, you are not supposed to include everything everywhere.

Originally Posted by meynaf

F.e. just include definitions for custom chip registers and see all your instances of "color" label fail miserably. Ouch.

I don't have "color labels". I have at best ".color" local labels which do not conflict, and some telling names for functions. Except that, I don't hit the custom chips directly. I'm using the Os (guess what). So SetRGB32() is your friend.

Originally Posted by meynaf

To avoid this, i must use a linker and thus put all the code in a separate source - actually several, as also "suggested". And assemble that separately.

Which is a good thing to do, since I don't have to reassemble everything.

Originally Posted by meynaf

That means object code must in some way be available for all programs using the includes.

Object code will be made available for all sources in the project, of course, and it is up to the make file to generate the object code.

Originally Posted by meynaf

Simple INCPATH in asm's config will no longer be enough.

Of course it will be enough. Why shouldn't it?

Originally Posted by meynaf

So either a program is built with several commands, or it uses some script or makefile.

Of course it will be build by a makefile. How else? Typing "make" is much less error prone than having to remember all the options. Miss one, and you get a different result - more source for errors.

Originally Posted by meynaf

And then a very nice (ahem) absolute path has to be added to the build process or it won't find the lib.

Why should a makefile have absolute paths? There is probably an assign for LIB: for where the amiga.lib is found, if you need it, and an assign for where the Os includes are, but that is about the only absolute paths that might be needed.

Originally Posted by meynaf

Now if i just want to write some small test program for whatever purpose, new code setup requires creating several files instead of just one.

If you write a small program, you don't need a makefile. But a small program is less than 5000 lines. You can still pull the os includes in, not a problem either.

Originally Posted by meynaf

And it's the end of me being able to create new small program in less than a minute.

My programs aren't small. I'm talking about professional development, not about toy programs. In toy programs, you have a short (~500 lines) program with a couple of INCLUDEs on top, and you build from the IDE. But that doesn't prevent you from using Os includes either.

Originally Posted by meynaf

The code within the library itself is no longer as lean and mean as before, as linkers can't directly optimise code (contrary to if/endc in the source).

What of a what what? Since when does a linker optimize something? And what for? If you are talking about small programs, who cares? If you write large programs, you'll need a linker. A link library, if that is your project, is typically hundreds of short asm files, put together into a common file, such that only minimal code portions are pulled out of it. Amiga.lib is build like this. Runtime "dynamic" .libraries are just programs.

Originally Posted by meynaf

Provided this is even possible : the library does a lot of magic like routine changes depending on cpu type, automatic error handling and resource tracking.

And why does that prevent proper usage of Os includes? I fail to see the connection. I can do resource tracking with Os includes all fine. With multiple source files even more so.

Originally Posted by meynaf

It would require using complicated, unwieldy things such as ctors and dtors, that i suppose not every linker will support.

That is not quite the matter of the linker, but of the startup code, but of course SLink supports that kind of stuff. But of course, clearly, that also works over multiple binaries, otherwise SLink would be completely broken.

Originally Posted by meynaf

And all that for the sake of having names in a source file i don't even touch often. It's just plain crazy.

You are just plain crazy, sorry. Type one number wrong, and search for your lifetime. Been there, done that. I don't have to repeat this experience, really. Yeah, crazy things you do as a kid, but I've grown up.

[lilalurl]

Hmmm, could you guys avoid calling other members names and remain on topic?

I'd prefer not having to lock the thread and do some cleaning up.
There seem to be relevant arguments in most posts, but there are too many personal attacks around these.

[meynaf]

Originally Posted by Thomas Richter

I already know enough by the number of lines. That is too much, and too long. Split things up into smaller files. Of course, for assembly, files grow larger, but that still sounds too much by a factor of two at least.

Current version is 8000 lines
Sorry, but splitting for the sake of splitting has no sense. If things belong to the same module, they should be in the same file.

Originally Posted by Thomas Richter

A worthwhile investion of time. Readable code.

And again you take as granted something i clearly did not agree with.
And no, it's clearly not worth. There is cost/benefit ratio in doing it, and the cost is very high for a very small benefit.

I know everything that's in that code because i put it in. So i can estimate the impact of changes. And i can tell you that what you suggest would result in catastrophic impact, wasting a lot of time and leading to a worse situation than before.

Originally Posted by Thomas Richter

Assembly doesn't have namespaces. Well, at least not the regular assemblers. It is common to use three-letter or two-letter structure acronyms to identify where the name belongs. Worked quite well for me.

Assembly has a global label namespace, and a different one for directives/macros.
I avoid polluting both, by doing exactly what you describe here (acronyms).
However, by far not all OS includes do the same !

Originally Posted by Thomas Richter

Also, you are not supposed to include everything everywhere.

Of course not, but a few files are enough to trigger conflicts.

Originally Posted by Thomas Richter

I don't have "color labels". I have at best ".color" local labels which do not conflict, and some telling names for functions. Except that, I don't hit the custom chips directly. I'm using the Os (guess what). So SetRGB32() is your friend.

I use LoadRGB4 and LoadRGB32, but it's not the point. It was just an example. There are many other possible naming conflicts.

Originally Posted by Thomas Richter

Which is a good thing to do, since I don't have to reassemble everything.

There is zero benefit in not having to reassemble everything, and a cost : lots of object files polluting the source directories.

Honestly, 100+ files doing the job of 1, where's the point ?

Originally Posted by Thomas Richter

Object code will be made available for all sources in the project, of course, and it is up to the make file to generate the object code.

Yes but this is where the problem lies : there needs to be a project file / directory. Even when the program is a small one.

Originally Posted by Thomas Richter

Of course it will be enough. Why shouldn't it?

INCPATH i'm using is located in phxass/phxoptions (in env or something like that, i don't remember exactly). All sources can therefore access my include files. But it is for sources, not for objects.

Originally Posted by Thomas Richter

Of course it will be build by a makefile. How else? Typing "make" is much less error prone than having to remember all the options. Miss one, and you get a different result - more source for errors.

But the fact is that i don't have any option to remember. I type "phxass source.s" and everything is done in a second. So a makefile is overkill.
It's not like C with dozens of options. What kind of options could be there in an asm program ?

Originally Posted by Thomas Richter

Why should a makefile have absolute paths? There is probably an assign for LIB: for where the amiga.lib is found, if you need it, and an assign for where the Os includes are, but that is about the only absolute paths that might be needed.

I don't have such assigns, obviously.

Originally Posted by Thomas Richter

If you write a small program, you don't need a makefile. But a small program is less than 5000 lines. You can still pull the os includes in, not a problem either.

But the problem is that i will no longer be able to write a small program without using the makefile, because said small program would use my lib.

Originally Posted by Thomas Richter

My programs aren't small. I'm talking about professional development, not about toy programs. In toy programs, you have a short (~500 lines) program with a couple of INCLUDEs on top, and you build from the IDE. But that doesn't prevent you from using Os includes either.

Oh, the "serious" big stuff again.
Sorry, but professional development is a different matter. I don't code professionnally like i code on the miggy, obviously. One is for a living, the other for the fun. If you code the same on both, you spoil the fun.

Originally Posted by Thomas Richter

What of a what what? Since when does a linker optimize something? And what for? If you are talking about small programs, who cares? If you write large programs, you'll need a linker. A link library, if that is your project, is typically hundreds of short asm files, put together into a common file, such that only minimal code portions are pulled out of it. Amiga.lib is build like this. Runtime "dynamic" .libraries are just programs.

Of course linker don't optimise ! That was the point. The only thing they can do is remove whole blocks of code.
I don't see an interest in having hundred of asm files leading to larger, slower executables, in comparison to single file leading to good code.

Originally Posted by Thomas Richter

And why does that prevent proper usage of Os includes? I fail to see the connection. I can do resource tracking with Os includes all fine. With multiple source files even more so.

It does not directly hinder the use of OS includes. However using a linker makes the matter more complex.

Originally Posted by Thomas Richter

That is not quite the matter of the linker, but of the startup code, but of course SLink supports that kind of stuff. But of course, clearly, that also works over multiple binaries, otherwise SLink would be completely broken.

My startup code is clean and i would prefer avoiding to split it in multiple parts. But as it opens only things that are needed, it is not possible with a linker.

Originally Posted by Thomas Richter

You are just plain crazy, sorry. Type one number wrong, and search for your lifetime. Been there, done that. I don't have to repeat this experience, really. Yeah, crazy things you do as a kid, but I've grown up.

Stop name calling please. It leads nowhere.

And i don't type numbers wrong. I copy-paste them, so in some way the computer is doing it. Never had a wrong number.
What you did in the past is certainly not the same as what i'm doing today.

Originally Posted by lilalurl

Hmmm, could you guys avoid calling other members names and remain on topic?

I'd prefer not having to lock the thread and do some cleaning up.
There seem to be relevant arguments in most posts, but there are too many personal attacks around these.

I am afraid the original topic is just dead. Everything starting with post #6 could just be deleted, if not the whole thread altogether. I has really gone haywire.