|Free x86 C compiler wanted email@example.com (Jean-Sebastien Stoezel) (2007-04-06)|
|Re: Free x86 C compiler wanted ArarghMail704@Arargh.com (2007-04-06)|
|Re: Free x86 C compiler wanted DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-06)|
|Re: Free x86 C compiler wanted firstname.lastname@example.org (Christof Meerwald) (2007-04-06)|
|Re: Free x86 C compiler wanted email@example.com (cr88192) (2007-04-06)|
|Re: Free x86 C compiler wanted firstname.lastname@example.org (George Neuner) (2007-04-06)|
|Re: Free x86 C compiler wanted DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-08)|
|Re: Free x86 C compiler wanted email@example.com (George Neuner) (2007-04-08)|
|Re: Free x86 C compiler wanted firstname.lastname@example.org (Nils M Holm) (2007-04-08)|
|Re: Free x86 C compiler wanted email@example.com (Aaron Gray) (2007-04-11)|
|Re: Free x86 C compiler wanted firstname.lastname@example.org (glen herrmannsfeldt) (2007-04-11)|
|[2 later articles]|
|Date:||6 Apr 2007 22:58:43 -0400|
|Posted-Date:||06 Apr 2007 22:58:43 EDT|
"Jean-Sebastien Stoezel" <email@example.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.
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
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
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
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):
__start: ;what this is doesn't really matter much
mov ax, cs
mov ds, ax
mov es, ax
mov ss, ax
mov sp, 0xFFFF
jmp $ ;freeze
db "STUB Sanity String"
dunno if this helps any.
Return to the
Search the comp.compilers archives again.