68k CPU pause (bubble)
 

Hi
I am wondering if Vasm warn the user if the code that it assemble Will cause pauses on the CPU aka bubbles that way he could re arrange or change it to avoid them. One also can think of an optimization level where the code is re arranged automatically?

I don't think warning for "pauses" is truly viable.

Meaning, I suppose you could create something that detects loops and if you then emulate the full logic involved* you may even detect that loops take a long time. But you'd have no way of knowing if this is by design or not. Pretty much all code contains loops that run a long time on purpose. You'd get warnings for perfectly logical stuff all the time in such a scenario.

Optimization is already possible to a certain extent in VASM, but the level you're asking for here will probably be hard or impossible to do - it's not as easy as you might think to rearrange code significantly without changing it's meaning. Which might make debugging a nightmare.

Plus, on a more serious level - I believe that programmers learn and grow by making lots of mistakes. So an assembler that tries to hide or optimize your mistakes away seems like a bad idea in that regard. You learn more by having your program slow down to a crawl and then figuring out what's going on than you do by never seeing the slow down because of a smart assembler ;)

*) Which IMHO is way, way, way out of scope for what an assembler should be doing

I think what Kamelito's asking for here is for the assembler to warn when the scheduling of consecutive instructions is suboptimal for the target CPU (i.e. hazards and bubbles), rather than anything related to the actual logic of the program?

Oh, right... I see what you mean. Didn't consider that because I tend to code for 68000 only :p

Anyway, that does change things quite a bit, yeah. Might be a very useful feature and a lot more doable than what I thought he meant.

Such a feature would have to have a way of turning it on and off at specific places in the code. I mean, I'd never want to go through a gazillion such warnings for non-critical code just to find the few warnings about overlooked bubbles in the critical loops.

As far as I know code scheduling makes sense for the 68060 only. But I think that rearranging code is nothing an assembler should do.

This step is usually done by a separate scheduler program, which reads the source and parses all instructions for their register- and instruction-unit usage and latency. Then it outputs a source with rearragned instruction lines.

vbcc has such a portable instruction scheduler (vsc.c), but currently only support for 603/604 PowerPC exists. It also depends on the compiler inserting "#barrier" or ";barrier" comments into the source, to define the barriers which should not be crossed by rearrangements. Otherwise it would be much too difficult to analyze the program flow.

So basically this is kind of software OoO at assembler level...

This is useless for pure 68000 as AFAIK it does not have instruction scheduling issues -- and other cpus of the family don't have many of them anyway.
Also needs to be specific for 020-030/040/060 for which sheduling is different.
There must be complicated hazard detection to avoid false positives (= cases where the instructions can't be swapped without changing the behavior).
Presence of labels is of course to be taken into account (an instruction can hardly be moved at the other side of a label without changing behavior).
And as already said, it is useless for code that's not time critical (= most of it).

At the end, while in theory possible this would be a lot of work for very little benefit...

It sounds like "Pairing" used by 68000

More you can find there in "Stage 3" in that document:
http://pasti.fxatari.com/68kdocs/Ata...eCounting.html

I wouldn't say that 'pairing' as described in the article is a 68000 concept; it's rather an artefact of the ST bus design

the same case exists in Amiga when CPU has access to the ram every second slot. E.g. in 16color mode