Wow. Just wow. I am not keen on assembler, but I can quite well understand what is going on here. OpenWatcom cdecl is nicer for debugging because it generates a frame pointer on the stack. Fastcall makes smaller (and likely faster) code. Both blow bcc away (which I'm not even sure what all the code it's generating is doing, or much less even needed) OMF is the Object Module Format defined by Intel for the 16-bit PC OSes. It's nearly universal as a format during the 16-bit DOS, OS/2 and Windows era. Watcom still uses it for two reasons: 1.) It has support for segments, including in the OMF-386 variant. 2.) Near universal compatibility with the vast majority of 16-bit development systems for DOS, OS/2 1.x, and Win16 in existence. See http://en.wikipedia.org/wiki/Relocatable_Object_Module_Format for a basic brief. As for interpreting the format, see http://www.azillionmonkeys.com/qed/Omfg.pdf (it's worth noting that "omfg" is probably an accurate response to OMF as an object format. Especially after reading this doc.) Sent from my HTC Inspire™ 4G on AT&T On Sun, Feb 19, 2012 at 16:36, David Given <dg@xxxxxxxxxxx> wrote: > On 17/02/12 22:51, David Given wrote: > [...] >> Regarding C compilers --- has anyone ever tried Open Watcom? It claims >> to support all these weird 8086 segmentation modes, and there is a Linux >> version. It's also supposed to produce pretty decent code, which may >> well be more compact than bcc's and so save crucial kernel space. Never >> touched it myself, though. > > I just had a play. Apparently Open Watcom produces OMF object files, > which none of myself, binutils-multiarch or file have ever heard of. > Rumour has it that the Open Watcom linker is capable of being scripted > --- I don't know whether this is to a useful extent. > > OTOH the code is definitely good. Here's a source file: > > int global; > > fnord(a, b) > int a; > int b; > { > int i = a + b; > int j = global - a; > global += i; > return j; > } > > (K&R C because I wanted to use the same file for Open Watcom and bcc; > Open Watcom supports ANSI. It even supports some C99.) > > In fastcall mode, Open Watcom produces: > > 0000 @fnord: > 0000 01 C2 add dx,ax > 0002 8B 1E 00 00 mov bx,word ptr _global > 0006 29 C3 sub bx,ax > 0008 89 D8 mov ax,bx > 000A 01 16 00 00 add word ptr _global,dx > 000E C3 ret > > In cdecl mode, it produces: > > 0000 _fnord: > 0000 55 push bp > 0001 89 E5 mov bp,sp > 0003 8B 46 04 mov ax,word ptr 0x4[bp] > 0006 8B 56 06 mov dx,word ptr 0x6[bp] > 0009 01 C2 add dx,ax > 000B 8B 1E 00 00 mov bx,word ptr _global > 000F 29 C3 sub bx,ax > 0011 89 D8 mov ax,bx > 0013 01 16 00 00 add word ptr _global,dx > 0017 5D pop bp > 0018 C2 04 00 ret 0x0004 > > bcc produces (and you may want to brace yourselves): > > _fnord: > push bp > mov bp,sp > push di > push si > dec sp > dec sp > mov ax,4[bp] > add ax,6[bp] > mov -6[bp],ax > dec sp > dec sp > mov ax,[_global] > sub ax,4[bp] > mov -8[bp],ax > mov ax,[_global] > add ax,-6[bp] > mov [_global],ax > mov ax,-8[bp] > add sp,*4 > pop si > pop di > pop bp > ret > > Note that that last is without optimisation; when I try -O I get an > error message about not being able to find /usr/lib/bcc/rules.start. Is > optimisation supported for the 8086? Also I notice that the bcc code > seems to be returning the value in ax, so I may not have got the calling > conventions to match. > > If anyone actually wanted to use this, I suspect the easiest thing to do > would be to compile with Open Watcom, disassemble the object files and > use a script of some kind to convert them to gas syntax. Which would > suck, but is almost certainly easier than adding OMF support to dev86. > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── > │ > │ "Never attribute to malice what can be adequately explained by > │ stupidity." --- Nick Diamos (Hanlon's Razor) > -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
