C++ on Amiga

[Karlos]

I use C++ on the 68k miggy all the time. It's fine, provided you know what you are doing. It's also a lot more convenient than C at times.

If you use heavyweight features like templates and RTTI, you'll get bloat, but metaprogramming and reflection aren't free.

On the other hand, you can create code that is effectively "C with classes", that is both compact and fast.

[Karlos]

I was looking at trying to learn E, but now believe it's useless to spend time learning it when I could be learning a language that would both lend itself well to the above situation and be useful outside the Amiga.

To be fair, this is why I've never really bothered with amiga specific programming languages. Whatever I can't implement efficiently in C/C++, there's always assembler

[Karlos]

C IS slower than assembler. GCC's code optimization is a joke. Why is ffmpeg for the 68060 twice as fast with a few assembler routines compared to all C routines? I don't know much about C++ compared to C but I have seen too much assembly output from C programs to believe C is as fast as assembler. Plus I can beat it 95% of the time with assembler.

This may be true for m68k compilers of the vintage in use on the amiga, but it isn't necessarily true of compilers in general. In any event, C and C++ both let you use assembler where you aren't satisfied with the compiler's code generation efforts.

Writing something entirely in assembler is massively wasteful in terms of development time.

[Karlos]

NOOB QUESTION INCOMING

Does the 3.9NDK work with C++ or just C?

It works fine with both, with one caveat. In C++, the use of the struct keyword when referring to a type is deprecated. This can lead to an ambiguity (it happened to me once) where you have global variables and structures with the same name.

Somewhere in your NDK, you have:

extern struct IntuitionBase* IntuitionBase;

Now, this is isn't great. It isn't a good idea to mix up variable names and structure names.

However, in C:

IntuitionBase = (struct IntutionBase*)OpenLibary("intuition.library", 0);

is fine. The global variable on the left of the assignment is completely distinct from the typename on the right, due to the struct keyword.

In C++, this above use of the struct keyword is deprecated and can cause your compiler to moan. However, removing it, can cause a problem:

IntuitionBase = (IntutionBase*)OpenLibary("intuition.library", 0); // huh?

The compiler may not know how to interpret the left hand side. Is it an incomplete reference to something?

The solution that worked for me is to disambiguate the reference by explicitly pointing out the global namespace, using the scope of resolution operator ( :: ), thus:

::IntuitionBase = (IntuitionBase*)OpenLibrary("intuition.library, 0);

Now the compiler knows you mean the global variable called IntuitionBase, and not the type name IntuitionBase.

A few of the headers may require modification to work under C++ but don't ask me which ones. They will all work under C though.

If you keep the caveat above in mind, this isn't the case.

[Karlos]

JIT is better than classic interpreted languages, yes. It still imposes a penalty, and it still makes zero sense in this age of free reasonable-quality compilers for every major architecture and most minor ones, especially when you're targeting a platform you know has one of two (maybe three) architectures.

In the right circumstances, JIT can outperform statically compiled code. Many things which are variables at compile time, end up being nearly constant at run time, whether they are some settings values or infrequently changing variables. Wherever conditional code depends on these, a clever JIT can fold out code in it's translation cache until those variables actually change. You can imagine the effect this can have on tight loops were you are able to remove a bunch of checks because you happen to know that at this instant during run time a whole load of them are invariant.

Even cleverer JITs don't bother compiling code that isn't compute bound and simply interpret it until a hotspot is found, reducing translation overhead as much as possible.

Using a combination of both, HP wrote a JIT called dynamo which actually "emulated" the same processor it was running on. Thanks to the effect of this late "run time" optimisation of code, it was able to outperform... itself :lol:

That is to say, a given piece of code executed directly on the CPU was slower than the same piece of code ran through dynamo on that CPU.

I've often though such an implementation would be ideal for something like coldfire because translation costs would be almost nothing and by running your 68K code through such a JIT, you can essentially catch the unimplemented opcodes/addressing modes as part of the translation steps, sidestepping the issue of whether or not you have any cases that you can't trap and emulate in the traditional fashion.

[Karlos]

Whaaa?  No AMOS Pro??

I did once try AMOS just to see what it was like. No offence to the author, but it was terrible. Absolutely everything about it felt alien and wrong. Not just the language, but the entire runtime and environment. Blitz Basic seemed much better from just about any angle you can compare them.