04 December 2020, 19:56 | #41 | ||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,217
|
Quote:
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. Quote:
Quote:
Quote:
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). |
||||
04 December 2020, 20:17 | #42 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
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). |
04 December 2020, 20:26 | #43 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,754
|
Quote:
Not in this case. 5000 lines of code you can easily include anywhere is quite convenient and easy to use. Quote:
Last edited by Thorham; 04 December 2020 at 20:32. |
||
04 December 2020, 20:30 | #44 | ||
<optimized out>
Join Date: Sep 2020
Location: <optimized out>
Posts: 321
|
Not wanting to talk for Thomas, but:
Quote:
Quote:
|
||
04 December 2020, 20:36 | #45 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,217
|
Quote:
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. |
|
04 December 2020, 20:49 | #46 |
<optimized out>
Join Date: Sep 2020
Location: <optimized out>
Posts: 321
|
|
04 December 2020, 20:49 | #47 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
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. 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. Quote:
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. |
||
04 December 2020, 21:41 | #48 | ||||||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,217
|
Quote:
Quote:
Quote:
Also, you are not supposed to include everything everywhere. Quote:
Quote:
Quote:
Of course it will be enough. Why shouldn't it? Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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. |
||||||||||||||
04 December 2020, 23:55 | #49 |
Global Moderator
|
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. |
05 December 2020, 09:03 | #50 | ||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
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. 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. Quote:
I avoid polluting both, by doing exactly what you describe here (acronyms). However, by far not all OS includes do the same ! Quote:
Quote:
Quote:
Honestly, 100+ files doing the job of 1, where's the point ? Quote:
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. Quote:
It's not like C with dozens of options. What kind of options could be there in an asm program ? Quote:
Quote:
Quote:
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. Quote:
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. Quote:
Quote:
Quote:
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. 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. |
||||||||||||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DoSuperMethodA without amiga.lib | meynaf | Coders. System | 26 | 06 December 2020 12:44 |
Wanted: P96 emulation.lib, rtg.lib autodocs, FD/LVO files | PeterK | Coders. System | 6 | 01 January 2015 19:59 |
DoSuperMethodA | mritter0 | Coders. C/C++ | 3 | 08 December 2014 06:56 |
Cinemaware posts Amiga games for download | Mangar | Amiga scene | 20 | 28 September 2004 04:47 |
"New Posts" does not show posts to News section? | fiath | project.EAB | 5 | 27 September 2004 13:23 |
|
|