Re: Free x86 C compiler wanted

"cr88192" <>
6 Apr 2007 22:58:43 -0400

          From comp.compilers

Related articles
Free x86 C compiler wanted (Jean-Sebastien Stoezel) (2007-04-06)
Re: Free x86 C compiler wanted (2007-04-06)
Re: Free x86 C compiler wanted (Hans-Peter Diettrich) (2007-04-06)
Re: Free x86 C compiler wanted (Christof Meerwald) (2007-04-06)
Re: Free x86 C compiler wanted (cr88192) (2007-04-06)
Re: Free x86 C compiler wanted (George Neuner) (2007-04-06)
Re: Free x86 C compiler wanted (Hans-Peter Diettrich) (2007-04-08)
Re: Free x86 C compiler wanted (George Neuner) (2007-04-08)
Re: Free x86 C compiler wanted (Nils M Holm) (2007-04-08)
Re: Free x86 C compiler wanted (Aaron Gray) (2007-04-11)
Re: Free x86 C compiler wanted (glen herrmannsfeldt) (2007-04-11)
[2 later articles]
| List of all articles for this month |

From: "cr88192" <>
Newsgroups: comp.compilers
Date: 6 Apr 2007 22:58:43 -0400
Organization: Saipan Datacom
References: 07-04-015
Keywords: C
Posted-Date: 06 Apr 2007 22:58:43 EDT

"Jean-Sebastien Stoezel" <> 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
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
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.

Post a followup to this message

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