68k CPU pause (bubble)

kamelito · 27 January 2020, 08:04

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?

roondar · 27 January 2020, 09:54

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

robinsonb5 · 27 January 2020, 10:27

Quote:

Originally Posted by roondar

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

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?

roondar · 27 January 2020, 10:30

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

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.

grond · 27 January 2020, 10:45

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.

phx · 27 January 2020, 12:21

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.

meynaf · 27 January 2020, 12:39

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...

Cyprian · 27 January 2020, 13:06

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

hooverphonique · 27 January 2020, 13:36

Quote:

Originally Posted by Cyprian

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

Cyprian · 27 January 2020, 15:09

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

27 January 2020, 08:04	#1
kamelito Zone Friend Join Date: May 2006 Location: France Posts: 1,801	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?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Bad weather for the 68K socket cpu cards	Solderbro	support.Hardware	0	14 July 2018 10:19
Selling A3660 CPU card, including Rev 5 CPU - NEW - professionally built	tbtorro	MarketPlace	1	17 June 2018 19:14
Looking to get max CPU performance in WinUAE 68k OS	GunnzAkimbo	support.WinUAE	1	12 May 2016 11:18
Pause during emulation	B14ck W01f	support.FS-UAE	1	03 January 2015 14:45

27 January 2020, 09:54	#2
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,408	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

27 January 2020, 10:30	#4
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,408	Oh, right... I see what you mean. Didn't consider that because I tend to code for 68000 only 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.

27 January 2020, 10:45	#5
grond Registered User Join Date: Jun 2015 Location: Germany Posts: 1,918	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.

27 January 2020, 12:21	#6
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	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.

27 January 2020, 12:39	#7
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	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...

27 January 2020, 13:06	#8
Cyprian Registered User Join Date: Jul 2014 Location: Warsaw/Poland Posts: 171	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

27 January 2020, 15:09	#10
Cyprian Registered User Join Date: Jul 2014 Location: Warsaw/Poland Posts: 171	the same case exists in Amiga when CPU has access to the ram every second slot. E.g. in 16color mode

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)