On Fri, Oct 3, 2008 at 4:00 AM, Mark Marshall <[EMAIL PROTECTED]> wrote: > Hi. > > So I've not got my bochs code into a form that I can easily distribute, so > that will have to wait for a bit. In the mean time (Actually why I was > bored at work) I've been playing with hq, hqasm and hqsim. Quite a nice set > of programs, good work there.
Yeah. I was rather impressed with them myself. These are going to really come in handy as we get more advanced. > First a bug report ;-) The assembler doesn't support '%' so It's hard to > load 32-bit constants. Or am I missing something? I came up with this, but > it also relies on me knowing that the low half is greater than 32767. > > ; load r6 with 123000000 > move ((123000000)/65536)+1, r6 > shiftu r6, 16, r6 > add r6, 54464-65536, r6 ; ((123000000)%65536) > > ; (We cant use 'or' because the constant is sign extended) > > I guess that for the very few occasions when this is needed it won't be a > problem. I think we can't do 32-bit immediate operands. > > So, what have I been doing? Well I had a go at converting draw_glyph into > HQ assembler. There were a couple of changes that I made - firstly the > bitmap was stored the wrong way around in the C version - the MSB of each > octet is the left most pixel. I made it little-endian intentionally. > Secondly I converted it to one Y loop instead > of a loop of 4 and a loop of height / 4. I think this makes smaller and > quicker code. That's probably fine, except that now you have to do checks inside the loop to decide if you want to pop another word out of the queue. So do you have the overhead of an extra outer loop, or do you have the overhead of conditionals inside one loop? I'm not sure if it really matters; it just made the code more readable for me. > Anyway I've attached my code as I'm not sure if it's ready to be checked in > or not. Feel free to do so if you like it. (The test section should be > moved somewhere else). > > > I think, from my reading of the other code mainly, that there is a delay > when we read from an external port? Is there also a delay when we read from > local memory? An instruction that fetches from scratch memory or I/O requires a delay slot. > For instance, if we assume that G_VID_SCREEN_WIDTH is local memory, I think > that this will fail because r0 does not have the value read from memory > until after the add. > > move [G_VID_SCREEN_WIDTH], r0 > add q0, r0, q0 Yes, I believe you are correct about this. > So this could be re-written: > > move [G_VID_SCREEN_WIDTH], r0 > noop > add q0, r0, q0 > > Is this correct? I'm a little out of it today, but yes, I believe so. The challenge is to find some other independent instruction you can fill into that slot. > > MM > > PS. > I probably won't be converting the rest of the VGA converter into HQ just > yet, this was just to see how it all hung together. I'll reply separately to your "neater" version. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
