C++ on Amiga

[AmigaHeretic]

Got it working finally.  Compiled my first SDL demo.

[itix]

@NovaCoder

C optimizing is getting better but it's not there yet with GCC 68k. GCC will do a pretty good job on some things and then add a nop or exg d0,d0 in there. I've been debugging Warp3D lately to try and fix a bug and I keep seeing those darn exg d0,d0. The wasted instructions even make for difficult reading. I wan't to fix everyone of them. For all the poor code, GCC code amazingly rarely crashes. The newest versions of GCC are worse at optimizing than the older versions by the way. I wouldn't be surprised if VBCC and SASC generate better code.

SAS/C is probably the best C compiler you can find for 68k. I havent used GCC 68k but VBCC is known to have problems with register allocation and generates sometimes slower code. StormC 3 generates only crappy code but StormC 4 should be ok.

Anyway when coding it is better code everything in C than in assembler. It is maybe slower on 68k but you can write and optimize code at algorithm level much better and faster than you ever would if you were writing everything in asm. Assembler is good for optimizations when you can not tune C code any further.

[unusedunused]

@NovaCoder

C optimizing is getting better but it's not there yet with GCC 68k. GCC will do a pretty good job on some things and then add a nop or exg d0,d0 in there. I've been debugging Warp3D lately to try and fix a bug and I keep seeing those darn exg d0,d0. The wasted instructions even make for difficult reading. I wan't to fix everyone of them. For all the poor code, GCC code amazingly rarely crashes. The newest versions of GCC are worse at optimizing than the older versions by the way. I wouldn't be surprised if VBCC and SASC generate better code.

i think warp3d is written with stormc3 because its begin lots before stormc 4 come, and need because of lib some specific compiler stuff so it cant without extra work run on stormc4 which use gCC.

that storm mesa is written with stormc3 you can see in the sources, there are asm files attach, stormc3 generate out of C source.

The most problem in C++ and all OO languages is, that its complete diffrent than a CPU work, and C++ allow lot features to write horribly slow programs that look in a csource only as a simple = and simple Term.

So i think its always usefull for write fast programs, that devs know about asm language, so they can see in debugger or profiler wy this program is so horribly slow.

But most programmers do not care about asm and dont know about the instruction their CPU use.and because X86 is a cisc cpu asm source is not so long as risc source, but still most dont know about X86 asm.

And thats the reason wy OO programs are mostly slower as C Programs and that win and linux programs need GHZ CPU to run well these days.

and as we see in kde or safari there is spend much work to speed up.
So the question is, is it faster to use C++ and go often in slowdown traps, and need time  to speedup and rewrite code so it look maybe not so OO clean.

I for myself dont like C++, it cost me lots more time, also on compiling.then this strange errors...
Maybe when there are entry level 10 GHZ 16 Core CPU out, maybe i change my mind. ;-)

then i think there need no speed optimization and it happen very very selden that you run in a C++ slowdown trap that make the program slow working.

[hayashi]

Sorry to gravedig, but I'm now trying to use the AHI-based ProTracker module library linked to earlier in this topic, and playback is horribly slow, freezes the program, and I haven't a clue how to properly use it. Could anyone help, please?

Thanks, Matt

[divined]

I`ve been developing games for directx some time now and always user a mixture of c and c++. I find that object oriented code clarifies your code a lot and helps with the debugging. Since, i`m thiking of returning to the roots and developing something on the AMIGA I would like to know which c++ compiler you recommend after all?
  Is this stromC 4 compiler the best available? Is it still commercially available?

best regards

George

[DavidF215]

  Is this stromC 4 compiler the best available? Is it still commercially available?

Alinea Computer (http://www.alinea-computer.de) is the current owner/seller of StormC4. It's listed in their online store.

[asymetrix]

Get a copy of Cubic IDE http://devplex.awardspace.biz/

It is a powerful package for programming C/C++, Hollywood, HTML and much more. It comes with vbcc and gcc (for sevral amigaish OSes) as well as a lot of documentation. The project mangement helps you with makefiles and to do your first "hello world" programm in C++ it takes only a couple of minutes.
Cubic is IMO one of the last software gems on Amiga & Co.

I used Cubic IDE, and its documentation is a joke, examples are few.

In the past i wanted help in trying to add LUA support to my project, and was basically given the middle finger for my efforts, this was a while ago.

Anyway we do need a C++ developer site, we need to code like the software houses so we can have tools that they can quickly use to compile to our platform.

We Amigans are stubborn and still love our assembler programming, this is why apps are so few - the world has moved on in OOP creating apps insanely quickly.

with 1 ghz processors we can afford a performance hit, in return for portability a development speed.

The industry standard is C++/C#/.Net we need to catch-up bigtime or we will never get all the great apps tools and Multiplayer games that our platform deserves.

Amiga was known for its games - but our super fast chipset dependent assembly language is stuck in code rot, assembler is not portable, hard to update, the hardware is not portable its high time we start thinking about platform independent coding.

Not just code that has calls that are OS interdependent, but libraries and GFX layer and GUI also independent.

In some cases our beloved datatype system is causing problems with porting HAM software or compression tools that use powerpacker for example.

Using datatype in apps stops porting of the app to windows for example, as no one knows how to create HAM modes / AGA export routines manually in code.

Look at windows paint packages all they possibly have is IFF/ILBM file format.

[psxphill]

SAS/C is probably the best C compiler you can find for 68k. I havent used GCC 68k

Years ago I used geekgadgets port of GCC (iirc 2.95), when I compared it to SAS/C I found GCC to be faster.
 
I tried various code generation options and I think telling GCC to generate 68000 code was the fastest across all processors.

[andst]

Hey, a C++ thread waking up  :-)   (any zombie thread rules on this forum?)

Are people doing C++ coding on Amiga these days?

What about tools and compilers, IDE:s, SDK, debuggers, etc?  Are they sufficiently up to date and on par with other platforms, or do people miss any significant features?

As I'm doing a 1.3 million line C++ Amiga project at the moment, I'm a bit curious to know if there is interest in C++ in general, and if there are any particular blockers.

//A.

[commodorejohn]

Anyway we do need a C++ developer site, we need to code like the software houses so we can have tools that they can quickly use to compile to our platform.

We Amigans are stubborn and still love our assembler programming, this is why apps are so few - the world has moved on in OOP creating apps insanely quickly.

Assembler versus HLL doesn't really have as much to do with development time as people think it does. Bedroom coders used to develop games in assembler in the space of a few months. It's more about scale of the project and going in with a definite plan but knowing what to cut if the schedule slips - tooling really is secondary to good software-development practices.

Besides, 68k assembler is nearly a high-level language anyway, particularly with a good macro-assembler. (And C++, being C-derived, is a lot closer to being a low-level language than any other object-oriented language!)

with 1 ghz processors we can afford a performance hit, in return for portability a development speed.

That philosophy is the entire reason modern PC software is such a mess.

The industry standard is C++/C#/.Net we need to catch-up bigtime or we will never get all the great apps tools and Multiplayer games that our platform deserves.

.NET is a prime example. Whatever its actual merits, it's largely being used as a poor man's UI toolkit the way Visual Basic used to be - but where the Visual Basic runtime was less than a megabyte, .NET takes up hundreds. (And, of course, it imposes a speed penalty just like every interpreted language ever has done - and it may seem like nothing much on your 2GHz i5, but it'll add up pretty damn quick on even a 1GHz G4 system, let alone anything slower.)

C++ can be lightweight, in the right hands - .NET will never be. The Amiga community does not need to see software that could be broadly useful stuck behind the wall of a massive runtime which it probably doesn't even need a tenth the functionality of.

Amiga was known for its games - but our super fast chipset dependent assembly language is stuck in code rot, assembler is not portable, hard to update, the hardware is not portable its high time we start thinking about platform independent coding.

Not just code that has calls that are OS interdependent, but libraries and GFX layer and GUI also independent.

The last thing we need is to join in the gradual transformation of every damn program on every platform into a generic POSIX/Qt mess that fits equally poorly on every operating system and requires pack-in support libraries for everything past C stdlib functionality, in the name of "platform independence."

It's one thing to port platform-independent apps from other OSes for the sake of filling some need that isn't adequately filled by native software (browsers, for instance.) It's another thing entirely to suggest that we should no longer have native software. Abstracting away everything that is different on one particular target for the sake of having only one codebase leads to what is essentially running an entire operating system on top of the operating system.

In some cases our beloved datatype system is causing problems with porting HAM software or compression tools that use powerpacker for example.

Using datatype in apps stops porting of the app to windows for example, as no one knows how to create HAM modes / AGA export routines manually in code.

Look at windows paint packages all they possibly have is IFF/ILBM file format.

So, what, Amiga developers should hamper themselves and their users by eschewing any functionality that isn't supported on other operating systems? Why should the principal concern of an Amiga developer be "will Windows users be able to run this?" If another OS doesn't support features that the Amiga does, then boo-friggin'-hoo for the other OS.



If having all of your software work equally poorly on every platform because it's actually written for some mythical golden-mean target OS is so important, let me suggest that Linux already exists, sir.

[NovaCoder]

Hey, a C++ thread waking up  :-)   (any zombie thread rules on this forum?)

Are people doing C++ coding on Amiga these days?

//A.

I don't do any C++ coding on my Amiga (too painfully slow), I still use gcc (cross compiler) on my PC.

Any 'modern' Amiga 68k targeted C/C++ development is very hard to do, the tools are just not up to the job.   I once spent weeks trying to debug a nasty memory related issue while porting ScummVM to 68k, this issue only seems to effect the 68k version of gcc and in any case, if I'd had a debugger I could have fixed the problem in about 5 seconds flat.

[psxphill]

.NET takes up hundreds. (And, of course, it imposes a speed penalty just like every interpreted language ever has done - and it may seem like nothing much on your 2GHz i5, but it'll add up pretty damn quick on even a 1GHz G4 system, let alone anything slower.)

It's not interpreted, it's just in time compiled. You can even pre-compile it on desktop/server operating systems.
 
The code generation isn't the problem, it's the bad code that gets through because the bar has been lowered & made it easier for rubbish programmers to get jobs.
 
Good algorithms in C# aren't slow. You can do good things on a 600mhz ARM processor for instance (and I have).

[commodorejohn]

It's not interpreted, it's just in time compiled. You can even pre-compile it on desktop/server operating systems.
 
The code generation isn't the problem, it's the bad code that gets through because the bar has been lowered & made it easier for rubbish programmers to get jobs.

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.

You're right, though, that actually being a good programmer makes more of a difference. That's true in just about any 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.

[EDanaII]

@ andst

What about tools and compilers, IDE:s, SDK, debuggers, etc? Are they sufficiently up to date and on par with other platforms, or do people miss any significant features?

I've tried many of them, from SasC, to Storm and Cubic on the Amiga. SasC and Storm come with debuggers, but I've only had luck with the Storm one. Like NovaCoder, I've had the most success using a GCC in conjunction with Eclipse, but, sadly, no debugger for it, although it may be possible to set up a remote debugger. I'm still figuring that one out.


@ NovaCoder

Any 'modern' Amiga 68k targeted C/C++ development is very hard to do, the tools are just not up to the job. I once spent weeks trying to debug a nasty memory related issue while porting ScummVM to 68k, this issue only seems to effect the 68k version of gcc and in any case, if I'd had a debugger I could have fixed the problem in about 5 seconds flat.

It may be possible to do remote debugging with Eclipse. I'm currently researching how it might be done. The tools appear to be there, so I'm just not certain how to set them up or if they will play well together yet.

I've opened up a query over on the new meant-to-be-a-Utilitybase-replacement forum. Anybody who has any ideas is welcome to comment either here or there on the subject.

[TheBilgeRat]

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

Whaaa?  No AMOS Pro??