Backend OMF structure

[TonyI]

Not really a bug per-se, rather an observation...

The compiler seems to be generating LEDATA32, PUBDEF32, and LINNUM32's when the offsets involved would fit just fine in the 16 bit variants of those record types.  In the case of the LINNUM32's this results in considerable bloat of the resultant OBJ, the others only waste 2-bytes per.

Here's some example output from an OMF optimizer I've been working on.  In this case the original OBJ was:

02/25/2007  08:31p              39,282 DUMP.obj

After munging it over and optimizing it it shrunk down to :

02/25/2007  08:37p              36,548 DUMP.obj

The gains came from:

Record morphing 32 bit to 16 bit Do3216Opt()
	4 SEGD32->SEGDEF(8 bytes saved)
	29 LEDA32->LEDATA(58 bytes saved)
	1 LIDA32->LIDATA(2 bytes saved)
OptLINN32()
	[16] LINN32 records converted to LINNUM records
	[2592] bytes saved in OBJ size
MvLinnToBottom() - 16 LINNUM/32 records moved.
LinnSort() - 15 LINNUM/32 record orders shuffled
LinnMerge() 15 LINNUM/32 records merged
Re-optimizing line numbers after dup purge
MvLinnToBottom() - 1 LINNUM/32 records moved.
LinnSort() - 0 LINNUM/32 record orders shuffled
LinnMerge() 0 LINNUM/32 records merged
2 EXTDEF/LEXTDEF/COMDEF/LCOMDEF/CEXTDEF type records merged
2 PUBD32  record elements merged

Adding an optimization to generate threaded fixups further knocked the OBJ down to:

02/25/2007  08:42p              34,366 DUMP.obj

Just under 5K off a 39K OBJ is a pretty decent reduction in size...