Re: Free x86 C compiler wanted

"Jean-Sebastien Stoezel" <js.stoezel@gmail.com> wrote
> I am looking for a free C compiler supporting 186 processors. Ideally
> the compiler would not generate code that is OS dependent (a
> bootloader would copy the code from PROM to RAM then branch to the
> program's entry.
>
> Right now I am using msvc, I thought it could work by generating COM
> files but I cannot succeed in starting my application (CPU not
> booting). I tried different symbols (__astart, __main...), nothing
> seems to boot.


any compiler supporting the 8088 or 8086 should work.


may help to check alt.lang.asm as well.


notes:
for this problem you may need to use assembler.


actually, if the project is small, assembler may well make more sense,
but it depends (hardly easy depending on how good you are with
assembler).


basically, the point is not that you jump to a certain label (such as __main
or __astart), but that you jump to a certain address.


first off, you have to know how your image will be aligned in memory.
for example, a com file is typically aligned at 0x0100, with address 0x0100
corresponding to the start of the file (0x0000..0x00FF is used for some
DOS-spefic data).


afaik, if it is a ROM, it is more likely to be aligned at 0x0000 (this
depends heavily on the loader, many may use a different address, ...).


alignment is very important if you have any hope of things actually working
(theoretically there should be an option for this in the linker).




now, here is the important thing (with com, and presumably a ROM as well):
your entry point, wherever it is, has to be exactly at the start of the
file;
this may be whatever, a small init function/stub, or simply a jump, but it
has to be right there (a stub, if used, will often complete tasks like
setting up the stack, making sure DS and ES are correct, ...).




usually, the way one will do this depends a lot on the linker, but usually
files are linked in some order, with either the first or last object file
comming right at the start (the linker may include some way of indicating
this as well).


one thing that can help here is that, immediately following the stub or
jump, you include some helpful descriptive string (something that can be
recognized in a hex viewer).




if following linking, you see the stub and helper string right where they
need to be, that is good.


as for alignment, this is usually controlled by the linker (sometimes this
can be specified in the assembler, but is usually only meaningful if the
assembler is doing raw binary output, and not if using object files).




a trivial example stub (assuming nasm-style syntax):
----
[section .text]
[bits 16]


__start: ;what this is doesn't really matter much
mov ax, cs
mov ds, ax
mov es, ax


mov ss, ax
mov sp, 0xFFFF


call _main


jmp $ ;freeze


db "STUB Sanity String"
----




dunno if this helps any.

Return to the comp.compilers page.
Search the comp.compilers archives again.