01 December 2020, 19:48 | #1 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
DoSuperMethodA without amiga.lib side posts
Mod note: problematic posts moved from http://eab.abime.net/showthread.php?t=104863
*********************************************************************** Look, do you think in 5 years from now, you remember what $18 was? For debugging, there is source level debugging, MonAm supports that. Last edited by lilalurl; 05 December 2020 at 10:08. |
01 December 2020, 20:46 | #2 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
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. |
|
02 December 2020, 08:35 | #3 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Do you think you will keep comments updated all the way? Comments on code are good, but code requiring comments is bad. Just use the tools of the language to make things obvious, then you can keep the comments for things that are worth commenting.
Quote:
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". |
|
02 December 2020, 10:19 | #4 | ||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
If code requiring comments is bad, then all code in the world is bad. If you think some code is obvious and is not worth commenting, think twice. Chances are good you are making a mistake. A comment that is there but not very useful isn't a problem. A comment that's NOT here where there should be one is a lot more problematic. Quote:
Besides, the source could be anywhere, including in an editor that's not even running on the Amiga (i.e. opened in np++ while the code is in debug in winuae - in windowed mode i can see both together). Altering the source as mistakes are found make said source obsolete in regard to any source level debugging. Quote:
I need a debugger that can trace into a function that's in input.device context (like the hook of a class). For obvious reasons Devpac can't do this. And i'm not talking about OS killing programs... Note that even though it's not my case, many coders use winuae's built-in debug facilities, of course without any source level possibilities. Quote:
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. |
||||
02 December 2020, 13:19 | #5 | ||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
Comments are good. Programs requiring comments are bad. Code should be to a major degree "self-documenting", so something like Code:
move.l $18(a0),a0 ;cl_Super Code:
move.l cl_Super(a0),a0 There is an even better alternative. Instead of wasting your time with commenting things that could be self-documenting, write *why* your code does something: Code:
; ok, method XYZ is not specific to our class, forward it to the super class move.l cl_Super(a0),a0 .... So, don't waste comments and typing to "obvious" things the assembler can do for you. Instead, comment motivation, structure and design, i.e. "higher level". In the same vain, Code:
addq.l #1,d0 ;increment d0 Code:
addq.l #1,d0 ;advance to the next index in the list These principles aren't new, aren't mine... Quote:
Quote:
Quote:
Don't kill the Os. The Os is your friend, not your enemy. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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] |
||||||||||
02 December 2020, 14:14 | #6 | |||||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Quote:
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. All programs require comments. But some bozos think their code is self-documented enough, and then the reader does not understand a thing when reading it. How many times did i find whole sources without even a comment saying what the source itself is for ! Is THAT the way of coding you want ME to use ?? Quote:
Code:
move.l $18(a0),a0 ; access to parent class pointer (cl_Super) Quote:
Of course i document why the code does something. All interfaces are fully documented, all routines tell what they do, etc. Quote:
Quote:
This strategy is called the strawman fallacy. I have never written such bogus comments such as you show above. Quote:
Not that i'm using it myself, i wrote my own many years ago. Quote:
I started 68k asm with devpac2 many years ago and will NEVER return to that. And no, devpac3 isn't better. Algorithms make programs fast. Micro-optimisations make them even faster. My picture viewer is the fastest currently available, and it's not for nothing. Quote:
Quote:
Quote:
I didn't design my coding style just for this, it's one of the reasons - no more, no less. But even though rarely needed, in our case here it really is ! Quote:
Quote:
Besides, instead of criticizing my way of coding, you could be helpful again and tell me the best way to force the rendering to use coordinates relative to the gadget and not to the window ? The provided RastPort doesn't do that. Quote:
Quote:
Quote:
But resourcing, yes, it's just a different way to go into other people's code. Does maintaining someone else's program count as "development" for you ? If yes, resourcing is the same. Quote:
Quote:
(In many cases i had to use a linker, etc, for other reasons, and it has always been a PITA.) Quote:
I know and have tried both options. Can you say the same ? |
|||||||||||||||||||
02 December 2020, 14:34 | #7 | ||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
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. I want you to comment what's worth commenting, and use clear code structure otherwise. I can only repeat: Many comments are good, code requiring many comments is bad. Your "anti-style" requires many comments, which is bad. Instead, comment non-obvious stuff. Quote:
Quote:
Code:
move.l $18(a0),a0 ;cl_super Quote:
Quote:
Quote:
Quote:
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. |
||||||
02 December 2020, 15:10 | #8 | |||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
I could tell you the same. This brings nothing to the discussion. Quote:
But changing this way of coding would invade the whole program. It's not "anti-style" at all. Just something you can't understand/accept. Quote:
Quote:
Quote:
Be realistic, please. Nice theories don't work in real life. It does matter, both in speed and code size - especially when multiplied with big number. But the asm should do it for you - that's the point. Even compilers turn peephole optimisation on. But maybe they're wrong all the way ? Quote:
Fact is my code works and is fast. Quote:
Quote:
Easy to maintain is another illusion. Quote:
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. |
|||||||||
02 December 2020, 19:24 | #9 | |||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
In old ages, "includes" on Amiga were a bit painful, if you only had a single disk drive and little memory. But that doesn't hold anymore, for at least the last 25 years. There is no excuse not using proper tools. Quote:
Quote:
Of course a consistent readable style should be applied to the entire program. Quote:
Quote:
Quote:
Quote:
Quote:
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. Right now. What happens if you find a bug? How do you maintain it? You are creating "write-once, read-never" code. Quote:
Quote:
Quote:
You are creating the horrors, and not only by my own measures. |
|||||||||||
02 December 2020, 20:10 | #10 | ||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Quote:
In C the situation would be very different, as the compiler would check if the field is in the structure or not. Or if the value is in the enum. But in asm this doesn't work this way. Therefore using the name isn't worth its price (except if it's declared in my own source, for my own purpose). Quote:
Quite often, actually. Depends on the source. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Should be very easy - something makes me think you're not doing a lot of asm anyway. You can charge me of paying too much attention to micro optimisation, which you regard as a small detail. But i can do the same for you for this whole story : the information is there, and its location (instruction or comment) is totally irrelevant. (It would be important in a strong typed language, but here we're doing asm.) Quote:
Quote:
Quote:
Again it's not "anti-style". In the same way it is better to do : jsr -$228(a6) ; OpenLibrary than : jsr LVOOpenLibrary(a6) And this, because it is more readable. Comments in asm are aligned to the right of instructions. And the eye is there when it looks for infos. Another benefit of using the numbers is that you end up knowing the most common ones. And this is invaluable when debugging code you don't have the sources for. On the Amiga i am able to enter any program and do alterations in it. This counts a lot against the small detail of using the name in the instruction or in the comment. Quote:
There are things you regard as good practices and things you regard as bad practices. But you seem to be overgeneralizing this. Me, i am more pragmatic. When something is the right tool for the current job, i use it. This is what differentiates good programmers from average or bad ones. Quote:
Anyway, 6502 and 68k are different beasts. Quote:
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. |
||||||||||||||||
03 December 2020, 11:22 | #11 | |||||||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
Quote:
So you are sloppy? Why not do it the right way right away? 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. So, in how far does it matter whether it is 6502 assembler or 68K assembler? The problem is all the same. A low level language needs better tools. Writing out label names helps. Quote:
Quote:
Quote:
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. So either your algorithms are trivial ,or you spend a lot of time with hunting down "the right numbers". That is the *professional* part of it, right? Not only getting things working, but also getting it done efficiently. Apparently, you haven't done that either? Quote:
Drop the comment. Put the name right into the call. No, harder. Because there is useless information in the code such as the offset. Why should I bother about the -$228? That's useless information. Quote:
Quote:
Quote:
Quote:
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. Nope. Quote:
Quote:
So, what are your programs anyhow? And how can the users tell what you did in your assembler. Quote:
I already said. Harder to read, harder to maintain. Quote:
Quote:
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? |
|||||||||||||||
03 December 2020, 12:52 | #12 | |||||||||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Try making a working source out of an executable. Quote:
Quote:
Quote:
With this kind of point of view, there would never have any innovation. Quote:
And - but perhaps you didn't get it - it's only about OS includes. My own structure fields have names. But it is true. When something is the right tool for the current job, i use it. Quote:
Quote:
Quote:
Enough damage, you mean ? Apart that it is not in any way harder to read. You failed to prove using OS includes improves things in any manner. Quote:
Quote:
Quote:
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 ? |
|||||||||||||||||||||||
03 December 2020, 18:33 | #13 | ||||||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
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.
Oh, and you think you are the only one doing it right, and everybody else does it wrong, and you haven't tried to change your style, just as learning experience? That's what I call "stubborness". Quote:
Quote:
That works even better, yes. At least in most cases. In the remaining cases, you need an assembler, but even that tool need to be used properly. Quote:
It's the job of the debugger to show symbolic names. It's not hard to do that with library offsets, every debugger I know does that. It's not hard to find and run a source level debugger either. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
No, it is the absence of modularity - exactly the opposite. You have now one big dependency, and rebuild everything just if one single detail change. It works the other way around: One include per module, so you only have to rebuild what depends on this module. The reason for modularity is to isolate information between modules, thus to decrease the dependencies. If you just put everything into one file, you could also put all sources into one file. Same shit. Quote:
Quote:
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 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. Exactly not, with numbers in it instead of names. 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. |
||||||||||||||
03 December 2020, 20:11 | #14 | |||||||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Quote:
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. You seem to be quite a specialist in that area. Quote:
Quote:
Quote:
Quote:
Quote:
Invalid argument (petitio principii). I have not in any manner agreed that it's harder to read. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
And again, IT IS ONLY FOR OS INCLUDES. So it has nothing "very fundamental" and isn't an error at all. Quote:
Initially some modules were in separate files and it didn't work very well. And of course end user of the library shouldn't have to care in which module some function is located. Frankly, as an example should i separate simple console print from file open in different modules ? Quote:
Quote:
Anyway i'm not using a linker (unless i mix with C code) and building everything is a simple command - can't be simpler. Quote:
Quote:
AGAIN: It's just OS includes i don't use. My own structure members have names. Quote:
Quote:
Did i tell you it was only for OS code that i use numbers and there is no OS code in the program itself because it is hidden away in the include ? Quote:
So let me retry : can you say the same about your asm code ? |
|||||||||||||||||||||
03 December 2020, 21:26 | #15 | |||||||||||||||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
Quote:
Quote:
I'm also using VisualStudio at work, or GoldEd on Amiga... whatever works for the job. However, as soon as the project becomes more complex, a tool to resolve dependencies is needed. IDEs are not as flexible as makefiles. Or cmake, or whatever tool you use for that. Quote:
Quote:
Quote:
Still enough people with more experience than those of you and me combined. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
In which way? So what makes Os includes special compared to your includes? What makes hardware structure different to software structure? Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Then, why dou you write comments? The end user doesn't see comments either? Quote:
Quote:
Quote:
Quote:
Asm code is machine specific, naturally. I cannot write assembler that runs on 68k and x64 simultaneously. Quite apparent. |
|||||||||||||||||||||||
04 December 2020, 10:12 | #16 | ||||||||||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Again it's not unreadable. Stop that nonsense NOW.
You want a big proof sent to your face, really ? Quote:
Every coder reasonably advanced knows what $dff180 or $dff09a are. Frankly, do you really want me to include hardware/custom.i and hardware/intbits.i and write this horror instead : move.w #INTB_INTEN,intena Quote:
Believe me, my coding style is quite different now than it was many years ago. I think you know it, you're doing it every day. Think of me next time you have an assembly error. Quote:
Quote:
Quote:
Quote:
Added together we have something like 60-70 years of experience. Really, find someone who has more. Oh, it's very easy. It's when the debugger can't know the library base. Quote:
Quote:
Then, it's just a matter of copy-paste. It's not as if there were OS tag values scattered all over the place in my programs. Now consider static initialization of a gadget structure with DC directives. There you can't use your beloved names anymore, you have to know the structure layout - i.e. the numbers. Quote:
Quote:
Quote:
Quote:
I don't remember all the gruesome details. Includes not found, version mismatch, no easy way to find in which include something was located, etc. Anyway, why should i prove anything ? After all, if you advocate a change, it's yours to provide the proof (else it is reversing the charge of the proof). So please speak about in which ways (with concrete and detailed examples) your experience with numbers got wrong. That would be more useful. Quote:
I don't need to include anything else. Always same name. OTOH, OS includes are many files scattered in many dirs. When using a function i like having it readily available and there they aren't. Quote:
Quote:
If not, you can not know why it can't work nicely. Quote:
Quote:
It could have been : should i separate video (frame buffer) handing from GUI parts ? PhxAss on Winuae JIT can assemble a 1MB program in less than 1 second. I think i'm covered Quote:
All that to say that "short enough" is actually the most common case, and i always optimise for the most common case. Treating all programs as it they were very big is a bad idea, really. Back in '98 or so i had to split a big program and use a linker because the A1200's 2mb weren't enough to assemble it. Then i got 030 with 16mb. Then i could merge it again. Phew. But i am able to do that again if needed. It is not a problem. However it is rarely needed, if ever, nowadays. Quote:
These modules will be different if you consider porting the code to another architecture. Same code could run on Atari ST or Mac OS 68k, maybe even Megadrive, with no change at all - only the includes would be different. And by converting the asm code in some automatic way (with a small vm), then it could potentially work on *any* architecture. Quote:
Quote:
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. 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. How can you be so wrong here ? All my names have prefix and i never had any conflict. And you will now pretend that OS includes don't pollute the name space ? This is nonsense. They do pollute it quite a lot and it is even one of the reasons for me not using them ! Quote:
I don't change the OS encapsulation code all the time. Programs using it do not need to be reassembled if new features get added in it. Quote:
Header files are for interfaces, not for structure. It only touches a small part of overall programs, i.e. the part that uses the host OS directly. So even if i admitted it was a messy way of doing, it would only affect a single source, actually, not the whole programs. But you here clearly assume it does. Quote:
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. |
||||||||||||||||||||||||
04 December 2020, 15:34 | #17 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
While I prefer OS includes too, I absolutely fail to see how this
Code:
move.l cl_Super(a0),a0 ;do whatever Code:
move.l $18(a0),a0 ;do whatever (cl_Super) |
04 December 2020, 16:16 | #18 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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? |
|
04 December 2020, 16:23 | #19 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
No the first one isn't guaranteed to be correct. It could be a member of another structure, or just every possible define.
|
04 December 2020, 16:27 | #20 |
<optimized out>
Join Date: Sep 2020
Location: <optimized out>
Posts: 321
|
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. |
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 |
|
|