Full implementation of aditional 8086 compatibility mode

[humbertocsjr]

My code is based on Pull request 33 from aleexmaftei.

Changes:

• Implementation of "-8086" flag on smlrc and smlrcc
• Implementation of macro __SMALLER_C_8086__, setted by "-8086" flag
• This new flag can be used with 32-bit modes, but generate bigger code without 386 otimizations on 16 bits.
• Create a alternative lcds.a library with 8086 code only, named lcds86.a
• When "-8086" and "-tiny"/"-dost" flags active, use new "lcds86.a" instead "lcds.a"
• Creation of "Use8086InstrOnly" global variable on smlrc and smlrcc, setted by "-8086" flag
• When activated change generation of (MOVZX, MOVSX, Bit operations, SETxx instructions, etc) to 8086 compatible equivalents.

[humbertocsjr]

I fixed the code errors that prevented it from compiling.

Now I've split CodeGen from the 8086 into a separate executable, and compressed the code enough so that it generates an smlrc using -doss exe

[humbertocsjr]

Usage of my modifications:

smlrcc -8086 -doss -o hw.exe hw.c

generate executable compatible with Intel 8086

If omit -8086 flag, compiler will ignore all my modifications, generating 386 code in 16 Bits

[humbertocsjr]

SMLRC86 in DOS Small and DOS Huge, has a limitation (only compiles with NO_EXTRAS flag)

[alexfru]

Now I've split CodeGen from the 8086 into a separate executable, and compressed the code enough so that it generates an smlrc using -doss exe

Such a smlrc isn't any more useful than the full one that uses 80386 instructions/registers and supports 32-bit types. At least, it's not any more useful alone. The rest of the binaries, e.g. the linker (smlrl) and assembler (nasm), would need to be 16-bit too so they can run on the purely 16-bit 8086 CPU. Right?

[humbertocsjr]

Now I've split CodeGen from the 8086 into a separate executable, and compressed the code enough so that it generates an smlrc using -doss exe

Such a smlrc isn't any more useful than the full one that uses 80386 instructions/registers and supports 32-bit types. At least, it's not any more useful alone. The rest of the binaries, e.g. the linker (smlrl) and assembler (nasm), would need to be 16-bit too so they can run on the purely 16-bit 8086 CPU. Right?

I just made this compaction to keep the "-doss" version compilable, I also think I find it unnecessary if you think we can discard a "-doss" version of the compiler, I can return the 8086 code generator code for a version more readable, I intend to gradually implement the 32-bit calculation in 8086, once again it will generate a much larger code than pure 32-bit equivalent, but it will be an alternative for those who want to compile the 8086/8088 as a target.

[humbertocsjr]

I cleaned up the 8086 code, and removed all the unnecessary extensions I had made to fit the compiler into the small model. I updated the code base to the most recent one from your project, for now the only output that this CodeGen generates is Tiny and Small, I'm seeing how I will implement a version of Large with multi segments for future versions.

[humbertocsjr]

I corrected the naming of the constants to be compatible with the format you use in other CodeGen, I added an error when trying to use OutputFormat incompatible with the -8086 flag, avoiding misuse, I imagine the code is now ready for production. I'm going to start a new branch to test 32-bit integer calculations using 16-bit commands and pointers with segments, I want to do it in a way that uses only CodeGen and not have to change the syntax (I don't intend to add the "far" modifier or do anything different, at most add the MK_FP macro used in old Turbo C/Microsoft C to set the segment). But the 16-bit integer code is ready.

[humbertocsjr]

I found an error when using smlrcc with the -8086 flag, I fixed it