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>
next in thread | raw e-mail | index | archive | help
>> > > > 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503030244.NAA13724>