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