Brainwaves

Posts to mailing lists relating to the graphical console have increased with the growing popularity of the amd64 port. I’m not at all surprised about this. In fact, I’ve seen it coming. That’s why I started vtc(4) development many moons ago. With KGI declared dead, vtc(4) may have grown another leg to stand on: a breeding ground for future KGI development. A new leg does not mean that vtc(4) has a more viable future. The fact that vendors of graphics cards keep their hardware under NDA is a real hurdle for vtc(4) and having proper drivers for graphics hardware is central to the design and implementation. If not for getting the higher resolution, real drivers are needed to get any kind of acceptable performance out of the hardware. Good performance is another hurdle that needs to be overcome. I just ran a kernel with vtc(4) under Parallels (a virtualization package that runs on Mac OS X for Intel processors) and scrolling was painful to watch. Interestingly, Parallels simulates Intel graphics hardware and Intel has documented what which is important to vtc(4). It would be interesting to write a driver for GMCH hardware with accelerated bitblt operations and see if there’s a performance increase. That’s an interesting experiment…

Now that I have implemented the conditional long branch emulation, it’s inevitable that I need to work on the long branch call form. This, however, requires some side-tracking. Emulating the brl.call instruction requires stack unwinding because it needs to get the value of ar.ec as it was at the time of the trap. It’s also possible that the brl.call instruction writes to one of the preserved branch registers. In that case, we need to know if that branch register was saved and where. Luckily, the runtime architecture states that b0 is to be used to save the return address, so we may ignore writing to other branch registers at first. Nonetheless, stack unwinding is necessary. This, by all means, is a good thing, because we need it in other situations as well—situations we’re not correctly handling now. Maybe I should import the latest libuwx first…