These only became obvious once ApplyModifier had been extracted, which
shrank the source code of ApplyModifiers by about 100 lines.
Even GCC 5 had seen that they are redundant and had not generated any
code for them.
This allows a return, instead of a variable assignment followed by a
break, saving a few lines of source code.
The size of the resulting binary shrinks as well, even though the code
is essentially the same as before.
- clockattach(): Allow multiple calls when running in Qemu. Anything
after this first one is ignored, but this gives us a change to use
a clock source provided by the VM directly, rather than relying on
a more expensive hardware emulation.
- Add cpu_initclocks_secondary(), to handle clock setup on secondary
CPUs, if needed.
- Allow us to use the WTINT PALcode call in cpu_idle() to idle in a lower
power state (Qemu's PALcode supports this).
- Use the Qemu per-cpu set-alarm-rel call as the hardclock interrupt
source. In Qemu environments, reduce hz to 50 (rather than the
default 1024) to give the clock a snowball's chance when running on
a host system with hz=100. XXX We have to manually re-calculate
tick and tickadj. There should be MI code to do this for us. Also
in Qemu environments, let hardclock() drive the sched clock by setting
schedhz=0.
The code size overhead of a varargs function is much more than I had
expected. Since GCC 5 didn't inline the function anyway and it is only
used in debug mode, there is no point keeping multiple copies of that
code around.
These two logging blocks are massive enough to disturb the reading flow
of the remaining code.
Even without these two blocks, ApplyModifiers is still 250 lines long,
which is quite much.
- no CRTC programming yet, we just use whatever mode the (open)firmware hands
us
- palette control, fb location etc. all work
- hardware acceleration for character drawing, scrolling etc. works
- hardware cursor works
... tested & still works on various radeons in various macppc machines
