A.D.A. Amiga Demoscene Archive

Thanks for the reply and the hint about the latest VASM features! From what I have learned over the last couple of days it looks like I will aim for a similar toolchain as well.

Btw. I just have my first hybrid c/asm effect running on a hardware screen with my old demosystem. It's really comfortable and so much faster now to control the motion with sin/cos functions. Time to celebrate for a bit!

yes. animating stuff with a sin table in assembler compared to c is so much fun that i'm happy if i never have to do it again :)

@noname: off-topic: did visiting bp bring back enthusiasm/motivation to code some amiga demostuff again? If so, awesome news and welcome back :)

on-topic: mixing of C and asm seems to make a lot of sense to me (from my limited experience with coding pure asm)

Speaking of this, I saw a post on a forum with a snippet of the code output from VBCC which contained several instructions such as link #0, subq.w #0, move.l a7, a7 etc. which hinted to that the back end was premature and would insert template blocks and just "blank out" certain instructions where needed.

Is there anyone here who has done some timing tests or has had a closer look at the output of the popular 68K compilers to get an idea which one has the most mature back end and generates the fastest code?

EDIT: actually it was GCC that did this and I got the impression VBCC did something similar because its output files grow in size so fast

@z5: Breakpoint was definitely great after many years of absence and I felt immediately home again with many familiar faces around and ready for a chat. Also, I feel motivated again to spend some time with my Amiga and fiddle around with "new" tools. So yes, I'm back in some way, but don't count on any releases.

@zeroblue: Can you give a link to that forum post? Also I wonder if a good optimizing assembler wouldn't polish that away?

Now that cross compiling with VBCC is working for me, I would be interested in having a look in doing the same with GCC.
- Anyone actually doing this and successfully linking the output with, say, Devpac, Phxass, or Vasm objects?
- Does anyone have a version of the modified GCC from StormC v4 that works under Windows? (compile time of this particular compiler isn't funny on the Amiga side)

Noname,

I can't recall what forum it was, but it was a case of multiplication where 10 out of 11 or so instructions were completely unnecessary. I don't think there are any assemblers that analyze code to an extent where they can optimize something like that away. I think it's a pretty complex task that you usually find in back ends for high level languages, at least I've only ever seen assemblers that optimize single instructions like move.l to moveq, absolute addressing to pc-relative etc.

You could try running that StormC GCC in WinUAE with JIT activated.

You might be right concerning the assembler not optimizing these kind of things, but I haven't checked.

Concerning StromC GCC in WinUAE with JIT, it is still too slow on my QuadCore. Can't work like that.

Out of interest, how many coders actually use c/c++ on Amiga and which productions have been coded in c mainly?

With the exception of this (where asmone was used to code the effects, phxass to assemble them, and sasc for the C framework) all my productions have been pure asm. As you can easily see, using C will greatly improve the [quality/development time] ratio! ;)

Back in 1998 I started working at a tool called ESA (Extra-Strong Assembly): basically, it allowed to insert high-level commands/constructs directly into assembly code - quick example:

move.l myownfunction[d0.b >= d1],d2

this would compare the lower byte of d0 with d1's, pass the boolean result to the custom function myownfunction[] and then store the return value to d2.
There is a lot more, like loop constructs, decisional constructs, etc. (who is interested can find plently of information on the website: http://saimobvq.interfree.it/ESA/index.html).
I thought this would be handy precisely for the boring tasks, without having to leave the assembly context.
I did not receive much feedback, so I guess not many found it useful. Anybody ever tried it? I'd be glad to hear your comments. I'd be even more happy if somebody found it useful for his own M68k coding ;)

The use of C on Amiga still intrigues me. It seems to be some sort of grey area: lots of different approaches to the tools being used and even more different opinions on whether there is actually any point in using it.

On top of that, i have a hard time imagining how a c coded demo looks like on Amiga (not the demo itself obviously, but the code). In asm, you shutdown the workbench, incbin some raw data (like pictures, fonts,...) and basically program using the 7 data registers and the 7 address registers. If you want to manipulate colors, you write them to the color registers (or use a copper list),... You include an asm music playing routine, compile and run. Winden once mentioned that asm was actually easier for that reason. You have direct and instant control of the data you include (or something along this line of thought).

Can anybody elaborate a bit more on how a c (or c/asm mixed) coded demo looks like. Do you move the mathematics over to c (which seems to me one very big reason to prefer c over asm). What do you actually move over to c? Can you write shutdown code in c? How to you include pictures,...

Frankly, i'm puzzled but intrigued. Does anybody has some basic c-skeleton for a demo that newbies could use as a start? Or is c on amiga not a good idea?

I'm asking because as somebody who loves to make demos from a "creative" point of view, i found asm to be a very tough nut to crack and not one bit enjoyable, tbh. The thought of moving stuff over to a slightly more "human" language sounds like music to my ears. I still know a bit of C from back in school long ago, but i have a hard time translating this into how a c coded demo on amiga looks like (from a structural point of view/approaching the amiga hardware, mixing asm in between, music player routines,...).

Since it is about time to do not only OCS/ECS 64kB intros and D!rt!e and Novel are nagging for a "real demo" ,
I'm interested as well to see such a skelleton / scripting code in C/C++.
Could perhaps also help DocK, who is quite a C-guy, to get away from the asm-hassle and pull up some
niftier stuff than an ordinary (yet systemfriendly etc.) Musicpack.

@z5

I think that using C on Amiga is quite confortable to test c2p effects or your ideas. On the other hand I wouldn't advise you to produce a pure C demo since speed won't be optimal even if your algorithm is very good.

If you feel curious you could prepare your asm code to be called from C as functions. I use Kalm's c2p with GCC2.95+PhxAss like this:

I have this function declaration in my C code:
extern void ASM c2p1x1_8_c5_bm_040( REG(a0,char *), REG(a1,struct BitMap *), REG(d0,ULONG), REG(d1,ULONG), REG(d2,ULONG), REG(d3,ULONG) );

Kalms phxass-fied sources look like this:
xdef _c2p1x1_6_c5_bm_040
xdef c2p1x1_6_c5_bm_040
.....
_c2p1x1_6_c5_bm_040
c2p1x1_6_c5_bm_040
movem.l d2-d7/a2-a6,-(sp)

....
movem.l (sp)+,d2-d7/a2-a6
.earlyexit
rts


Once you compile it with PhxAss you have to execute hunk2aout to get objects linkable with gcc.

If you want I could send you an interesting tunnel example done by an skandinavian guy. It multitasks but I guess you could exchange AmigaOS functions by your own functions progressively and kill the OS when you have completed the transition.

I have used C for loading, setup and precalculation mainly. SASC and PhxAss. Even in the old intros. On that type of code you win loads of devtime and nothing in speed time, perhaps you lose some in code-size but its worth it.

Though, I am a bit in the dark when it comes to the quality of code generated by Amiga C-compilers. Still, I'm guessing its the same as for most platforms. You need to check what you get. Test, profile and have some knowledge about the machine.

Example: Zeroblue mentioned the multiplication thing. Well.. that happens if you do 32 bit * 32 bit. (int) * (int). The result is 64 bit. Its possible to use the 64 bit instructions but they do not exist on 68060. So instead a general function call is generated. If you do (short) * (short) instead, SASC will use muls.w. Or you could compile specifically for 68040,030,020.

On occasion I have thought that the process of using an editor, compiler, assembler, linker and make; is a bit inelegant compared to asmone/asmpro way of coding. These days with PC and WinUAE JIT speed, its instant and fairly easy to automatize the whole deal and the 'inelegancy' fades away. .. until you start using a real machine. :)