So quiet in here?

[Karlos]

I like constexpr. It's nice being able to write something quite expressive, knowing it's going to cost compile time only.

[Jobbo]

I like it too, but unfortunately that doesn't seem to be what constexpr does every time.
Seems it’s only a suggestion that the compiler might ignore at any point.

[Karlos]

Originally Posted by Jobbo

I like it too, but unfortunately that doesn't seem to be what constexpr does every time.
Seems it’s only a suggestion that the compiler might ignore at any point.

It's allowed to. It can't anticipate certain side effects, so depending on what your constexpr qualified function does and how it's invoked, it may emit code or not. In the long running thread regarding C v asm, I posted a silly example of a compile time prime number generator. It compiles to a lookup table (and did, for 68K). It might amuse you.

https://eab.abime.net/showpost.php?p...&postcount=550

[FSizzle]

constexpr is unfortunately flawed, making it not that useful imo (since you can't "trust" it). C++20 adds constinit and consteval which are probably what constexpr should have been, with far stronger compile-time guarantees.

[Karlos]

Originally Posted by FSizzle

constexpr is unfortunately flawed, making it not that useful imo (since you can't "trust" it). C++20 adds constinit and consteval which are probably what constexpr should have been, with far stronger compile-time guarantees.

Trust it how? It's a hint, not a demand.

[FSizzle]

Originally Posted by Karlos

Trust it how? It's a hint, not a demand.

I mean if you require compile time evaluation, you cannot "trust" that constexpr will give you what you want, because it is only a hint as you say.

[Karlos]

Originally Posted by FSizzle

I mean if you require compile time evaluation, you cannot "trust" that constexpr will give you what you want, because it is only a hint as you say.

Sure. That said, I've yet to see it fail to produce a compile time evaluated result when the requirements for it are met. As soon as you add things that may have side effects, all bets are off.

Personally I tend to use it for simple decision making with "if conxtexpr" based on things like compile time type evaluation, as a way of reducing dependencies on various macros. An example would be the machine register definition in MC64K, which is just a union of supported word sizes (and pointers to them_:

https://github.com/IntuitionAmiga/MC...e/register.hpp

This allows the register to be accessed as a template, from other templated code at compile, always ensuring the correct element of the union is accessed. This comes in handy for other functions that are templated out, like vector operations

https://github.com/IntuitionAmiga/MC.../vec3.hpp#L117
https://github.com/IntuitionAmiga/MC.../vec3.hpp#L154

When these are eventually invoked for a scalar type, everything compile time evaluates to just accessing the union member in the expected way.

[Photon]

Tell everyone I'm back! - there are 100 ribbons on the old oak tree.

As for the C etc whatever: It really is lovely to hardware code in Assembly. The only reason for not running is because you mistyped an include filename, or misspelled a CPU instruction or symbol name, and the only reason for a program crash is again, only because of a mistake that you made. An oasis in a world gone crazy.

Not the accumulated tries and fails with any and all excuses to fail to compile or do so and crash, while all the time the code remains unchanged. Mostly only C/C++ and other "still in beta" languages suffer from this. AMOS, Basics etc were finished and provide a platform to target.

[Jobbo]

Photon, that definitely all true!!!

On Amiga I use C for my own productivity given the limited time I have and the sorts of things I'd like to make.

But absolutely it'll bite you hard at times. This is normally because the optimizer is bending the rules in ways that aren't obvious.

For example, I had to add memory barriers in one instance because it would reorder things before/after when I enable interrupts. That can be very bad!

[hop]

My bucket list includes writing an Amiga game in ASM, so I hope this forum is monitored by some old hands for a few more years because I'm bound to get stuck. I made a good start a year or so ago, but got sidetracked writing a mod to p61 converter in (minimal) C++ so it could form part of the toolchain.

[Thomas Richter]

Originally Posted by Photon

Not the accumulated tries and fails with any and all excuses to fail to compile or do so and crash, while all the time the code remains unchanged. Mostly only C/C++ and other "still in beta" languages suffer from this. AMOS, Basics etc were finished and provide a platform to target.

Unlike AMOS, C and C++ are looked at by an ISO commitee, and thus they only change when there is a consensus between experts to make a change. C90 is particularly stable - it hasn't been changed since >30 years since now, so calling it "beta" is really nonsense. You probably do not understand it well enough then.


Note, again, that I'm not saying that "C is the perfect language". It certainly is not, it has a couple of odditities you must be aware of, but it is a much better choice for many problems than assembler. But what is the right choice depends of course on the problem you want to solve. There is also AREXX and shell script on the Amiga, and certainly AMOS has also its merits even though I have personally not used it.



I personally use whatever is appropriate to solve a problem. That includes also java, C++, python (we do a lot in python recently), bash, it was also C# (even though it has "Micrsoft" written all over it) or whatever else it takes. It is like with human languages. Learn a language, learn a culture. The more you master, the better...

[Karlos]

Originally Posted by Thomas Richter

I personally use whatever is appropriate to solve a problem. That includes also java, C++, python (we do a lot in python recently), bash, it was also C# (even though it has "Micrsoft" written all over it) or whatever else it takes. It is like with human languages. Learn a language, learn a culture. The more you master, the better...

OMG you left out Rust! Rust is the only language that saves the developer from the horrors of memory, concurrency and the hideous dangers of variables that, you know, vary. Or at least that's what the indoctrination session... I mean introduction lesson said

[meynaf]

Originally Posted by Thomas Richter

Learn a language, learn a culture.

Except one that is the "wrong tool", huh ?

[Karlos]

Originally Posted by meynaf

Except one that is the "wrong tool", huh ?

I think the argument is that there are better tools depending on the task. You can carve wood with just a knife, but chisels, saws, planes and sanders all exist for good reasons.

[meynaf]

Originally Posted by Karlos

I think the argument is that there are better tools depending on the task. You can carve wood with just a knife, but chisels, saws, planes and sanders all exist for good reasons.

I don't think the comparison works. As chisels, saws, planes and sanders are not internally converted by some process to knives.

[Karlos]

Originally Posted by meynaf

I don't think the comparison works. As chisels, saws, planes and sanders are not internally converted by some process to knives.

Assembler is the knife here. Compilers haven't generally depended on producing assembly language for a separate assembler stage for decades. So no. Your woodworking tools don't need to be turned into knives. That's a throwback to say the least.

Compilers that retain the ability to produce assembly language today primarily do so that it can be inspected, debugged etc. Depending on the language and tooling you are using there may not even be any option to even generate assembly code. If you want to see it, you'd need to disassemble it.

In some cases trying to generate the assembly per source is counter productive or outright misleading because you may want to use whole-program/link-time optimisations where all of the notionally separate code from each source unit goes through a final round of optimisation that makes changes that are simply not representable in the assembly output of a single source unit.

[meynaf]

Originally Posted by Karlos

Assembler is the knife here. Compilers haven't generally depended on producing assembly language for a separate assembler stage for decades. So no. Your woodworking tools don't need to be turned into knives. That's a throwback to say the least.

Compilers that retain the ability to produce assembly language today primarily do so that it can be inspected, debugged etc. Depending on the language and tooling you are using there may not even be any option to even generate assembly code. If you want to see it, you'd need to disassemble it.

In some cases trying to generate the assembly per source is counter productive or outright misleading because you may want to use whole-program/link-time optimisations where all of the notionally separate code from each source unit goes through a final round of optimisation that makes changes that are simply not representable in the assembly output of a single source unit.

Come on, ML and ASM are basically the same thing.
And even if you don't admit this evidence, all these tools still need to be converted to some unique tool at one stage or another, and this is machine language.
And cpus take 100% of their time executing ML and absolutely nothing else.
So no, your tool comparison does not work.

[Karlos]

Come on, ML and ASM are basically the same thing

Are they though? Assemblers are allowed to make optimisations too. I think Bruce was fighting with the results of that, at some point. If you are doing some exact cycle counting or code size work (which is more likely if you are using it in the first place) the assembler changing an instruction for another with the same overall side effects isn't particularly desirable

Then you have macro expansions and other things that insert code you didn't explicitly write.

So while assembler is as close as you'll get to the object code in a human readable format, it's not identical, unless you explicitly disable any optimisation passes, never use any macos, always specify the exact, specific mnemonic for the operation at all times, etc. and don't rely on any "generic" variants like add (always using add, adda, addi, etc).

[meynaf]

Originally Posted by Karlos

Are they though? Assemblers are allowed to make optimisations too. I think Bruce was fighting with the results of that, at some point. If you are doing some exact cycle counting or code size work (which is more likely if you are using it in the first place) the assembler changing an instruction for another with the same overall side effects isn't particularly desirable

Hopefully assemblers are allowed to make optimisations. This way we don't need to care about branch sizes anymore, what a relief.
But you can turn them off if you want to. You can even do that locally.

Originally Posted by Karlos

Then you have macro expansions and other things that insert code you didn't explicitly write.

So while assembler is as close as you'll get to the object code in a human readable format, it's not identical, unless you explicitly disable any optimisation passes, never use any macos, always specify the exact, specific mnemonic for the operation at all times, etc. and don't rely on any "generic" variants like add (always using add, adda, addi, etc).

That doesn't make your comparison more valid.
As you seem to have ignored my all these tools still need to be converted to some unique tool at one stage or another, and this is machine language...
Tools are distinct, with no conversion. Computer languages are all converted to ML in one way or another. This is very different.

[Thomas Richter]

Originally Posted by meynaf

Except one that is the "wrong tool", huh ?

Assembler? Yes, for almost everything it is the wrong tool. Not for everything. Low-level driver code that interfaces hardware is probably the only exception that comes to my mind. P96 drivers are (to some degree) in assembler. For example, higher level code, like GUIs, are not the domain of assembler. It's just more work, and no benefit at all.