Date: Fri, 3 Mar 1995 13:44:27 +1100 From: Bruce Evans <bde@zeta.org.au> To: phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com, davidg@Root.COM, wpaul@freefall.cdrom.com Subject: Re: cvs commit: src/sys/i386/boot/biosboot probe_keyboard.c Message-ID: <199503030244.NAA13724@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>> > > > Modified: sys/i386/boot/biosboot probe_keyboard.c >> > > > ... >> > > > up alittle. This pushes us right up to the edge of the size limit: >> > > > the second stage boot is now 7152 bytes in size, just 8 bytes under >> > > > the wire. On the other hand, the new probe now does almost exactly 16 bytes under :-). >> > > This is going to be a problem...there are some (other) bugs that I need to >> > > fix that will require some bytes themselves. Time for a multi-stage boot. >> > There is plenty of bytes to spare, if we get all the "date16 ; mov this,that" >> > turned into real 16 bit instrs. Any takers ? 8 bytes here, 2 bytes there...but it will add up to only one or two hundred bytes. >> There is no such thing as ``real 16 bit instrs''. You have 8 bit inst and >> you have current mode inst, which are either 16bit or 32bit depending on >> the CS GDT entry size bit. You have to use data16; mov this, that when >> dealing with 16 bit values running in a 32 bit code segment. >You disasseble our boot1 and you will see what I mean... Yes, there are a number of what should be 16 bit instructions in 16 bit mode that are programmed as `addr32; data32; movl...' because it's too hard to do anything better using gas. This costs bytes for both segment overrides and longer effective addresses. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503030244.NAA13724>