How Close Is Blitz to ASM
 

Hi All.
Sometimes I have a feeling that Blitz Basic is just a "so-phisticated Macro Assembler".
My point is: it's very close to hardware programming (closer for sure than Amos)
Well most important thing is that I can start write Asm code whenever I want with no problems. I can control Copper How I wont or access biplanes to write to them directly. Hell I can do dc.w or incbin if I want to and later pass pointer to these structures to the routines.
but I have some questions to those who know the internals of Blitz. (or maybe we can guess)

1. are bitplanes interleaved for faster baiting? if so how is it possible that I can control separate biplanes with BitPlanesBitMap command?
2. if I use bbit or qblit how efficient is the blitter code?
3. figures like lines, plots, filled polygons - do they use glitter? can I assess they are optimal or should I write my blister replacements?
4. is using statements slower than gosub? (my impression is statements and functions are much slower)
5. how the compiled code compares to the C compiled code - optimisation wise?

I started working on game (more details soon but visit my other thread ;)) and I'm very glad of the results so far. especially code speed so far is OK.
so. lets talk about blits internals and maybe unveil how it works in it's internals.
Regards

Blitz2 source code is open. And yes, it is basically a macro assembler. With hickups.

5) The compiled code consists of entire libs (string-funcs, dos-io etc.) linked to the executable. so there is alot of unused routines. But the exec size is still acceptable. Not like hollywood, for instance.
Optimization wise it depends on the skills of the coder of those libs. of course you've got some overhead from saving regs to stack and malloc()s and so on while handling strings. but otherwise you can write your own commands in asm.

1. No, you'll have to roll your own interleaved code. This was discussed in depth on the BlitzList; you can find the mailing list archives on Aminet.
2. I guess it's about as efficient as general blitter code can be – keep in mind that it's been used for commercial games and is written by old-school assembly coders. That doesn't mean that it's as efficient as an experienced assembly programmer's custom code since it must cater to all kinds of cases and not just your specific game.
3. I don't know, but they're not very fast. You can find some assembly implementations in the 3D examples included with Blitz.
4. I've read as much, yeah. I try to use gosubs when optimising.
5. C code is usually better optimised simply because you're the one doing the optimisation when programming C (Amiga C compilers are quite a few years older than deep optimising compilers which turn out machine code quite unlike the original C code). You can make even more optimised code using inline assembly in Blitz. The Basic part of Blitz is quite far from optimised, so any arithmetics code will be less efficient than their C counterpart.

Procedures are known to be slower for a couple of reasons. First, any local variables are initialised at the start of the routine, since it's standard behaviour for variables to be initialised to 0 automatically. This takes time when compared with other languages that don't initialise variables. Strings and arrays also need time for assigning the memory buffers required. The time involved is quite tiny, but if you're calling a function hundreds or thousands of times a second, it starts to add up.

There is an option in Amiblitz 3 to create FAST procedures, which doesn't bother initialising variables or creating buffer space for strings or arrays. This means that local variables will be filled with garbage when you initialise them first, and you can't use arrays or strings inside the procedure, but it does cut the time down taken by procedures.

@All
thanks for answers. In most cases it's like I expected. I did found many Blitz Basic assembler examples f/e in Gloom source code and I think I will evaluate these areas even more.

procedures/functions is the area I started to optimise by using GoSub.
I saw in examples some people use BSR/JSR and RTS. Is is the same as GoSub/Return (I know it has the same effect)

Do I need to worry about blitter waits in Blitz2? If so, is there an assembly macro to do the check to see if the blitter is free, before doing the blit?

I think Blitz automatically waits for the blitter to finish drawing before giving it more stuff to draw. This wait seems to always happen at the beginning of all "Blit" commands, so you don't have to worry about it.

I have made speed tests on this, and have found out that programs run a lot faster when you alternate between blits and code like this: "Blit-Code-Blit", rather than having all code first and then many consequtive blits like this: "Code-Blit-Blit".

If there are two or more Blit commands one after another, with no other code happening between them, then Blitz and the CPU will do nothing between the two Blits until the Blitter has finished drawing the current graphics image. But if there is some code between the Blits, then that will be executed during the blitter draw, and this can speed up things a lot.

According to the manual, there is an interrupt instruction "Setint 6" to check the "glitter finished" status. But I'm not sure if that is used to check the Blitter draw finish status or something else, and I have never used it because Blitz itself takes care of the Blitter waits automatically.