Assembly code with Borland's C compiler

It's been ages since I fiddled with X86 assembly but this might help.

For "Borland C++ 5.5.1" (the version with BCB5), and running "bcc32 -S hello.c" on

I don't have time right now to dig into this. But could you post the error messages? The exact details of those you are getting?

I gather from the above you are using a Microsoft assembler's output and linking it together with the output from a Borland c compiler using the Borland linker. Another thing to keep in mind is that the records placed in the OBJ file (aside from naming issues you above suggest) might be somewhat different -- in short, the Borland linker may not recognize every record in the output of the Microsoft assembler. Though it may. I just don't know. The error messages may help to disambiguate here.

Jon

Unless I have missed something, this will generate a 16-bit object, and it looks like the c code (from below) is 32-bit. That generally don't work.

Try something more like:

.386 .model flat .code _wedtst proc ; awk (WORD gdtsize, DWORD flataddr) void public push bp ;save bp mov bp,sp ; -> stack frame mov eax, 66 pop bp ;restore bp ret _wedtst endp end

-- snip --

If I'm working with a tool chain that supports compiling to assembly I cheat. I write a framework file in C and compile to assembly, then find the insides of the functions and start writing code.

It may not be manly, but it works just fine.

Hehe. Cripes. In my rush to dash off a reply I didn't read the "mess" I saw below the OP's post. My fault. I'll look, later.

Jon

comp.arch.embedded Assembly code with Borland's C compiler

Anyone have suggestions regarding the form for assembley code files used with Borland's version C compiler? The code below, assembled by masm6, doesn't satisfy the linker (Borland's). The segment names are a guess for the most part - taken from masm6's accrued examples on other projects. "cs:DGROUP" appears off but, if the error is due to segment names, maybe someone here knows suitable names? The code & bat file & error messages are included below.

Hul

.386p public _wedtst

; Segments & groups DGROUP group _TEXT

_TEXT segment assume cs:DGROUP,ds:DGROUP

_wedtst proc ; awk (WORD gdtsize, DWORD flataddr) void public push bp ;save bp mov bp,sp ; -> stack frame mov eax, 66 pop bp ;restore bp ret _wedtst endp _TEXT ends end

%BC55PATH%\bin\bcc32 -c -tW -a4 -g20 -I.. -I%BC55PATH%\include windil.c > compout.txt rem %BC55PATH%\bin\brc32 -i%BC55PATH%\include windil.rc >> compout.txt %BC55PATH%\bin\ilink32 -L%BC55PATH%\lib -c -aa -Tpe c0w32+windil+wedtst,windil, NULL,import32.lib+cw32.lib,, >> compout.txt type compout.txt | more

comp.arch.embedded Assembly code with Borland's C compiler

Anyone have suggestions regarding the form for assembley code files used with Borland's version C compiler? The code below, assembled by masm6, doesn't satisfy the linker (Borland's). The segment names are a guess for the most part - taken from masm6's accrued examples on other projects. "cs:DGROUP" appears off but, if the error is due to segment names, maybe someone here knows suitable names? The code & bat file & error messages are included below.

Hul

.386p public _wedtst

; Segments & groups DGROUP group _TEXT

_TEXT segment assume cs:DGROUP,ds:DGROUP

_wedtst proc ; awk (WORD gdtsize, DWORD flataddr) void public push bp ;save bp mov bp,sp ; -> stack frame mov eax, 66 pop bp ;restore bp ret _wedtst endp _TEXT ends end

%BC55PATH%\bin\bcc32 -c -tW -a4 -g20 -I.. -I%BC55PATH%\include windil.c > compout.txt rem %BC55PATH%\bin\brc32 -i%BC55PATH%\include windil.rc >> compout.txt %BC55PATH%\bin\ilink32 -L%BC55PATH%\lib -c -aa -Tpe c0w32+windil+wedtst,windil, NULL,import32.lib+cw32.lib,, >> compout.txt type compout.txt | more

Thanks Rich - those segment names look like an improvement. I'll give them a try.

Hul

Rich Webb wrote:

doesn't

Jon - as you suggest, mixing Borland & MS object code requires optimism. The error from the linker is at the bottom of the message.

Hul

J> > >comp.arch.embedded

doesn't

I'll give it a try & see what happens.

Hul

snipped-for-privacy@not.at.arargh.com wrote:

doesn't

c0w32+windil+wedtst,windil,

function

Tim Sounds good - I'll try it.

Hul

Tim Wescott wrote:

And DON'T use '/coff' on the command line. You should get 32-bit OMF files, which is what I think the Borland linker expects. Never used Borland products, so don't really know.

I always recommended that method. Particularly when people wanted in line assembly or a small amount of assembly in a C program.

write an empty c function call, with all the parameters, compile to assembler and out the body in by hand.

This sorts out all the parameter passing and you can call it with a standard C include file. Much more efficient.

Of course at one time all compilers went to assembly code Then you assembled and linked. Actually even the compilers tended to be 3 pass affairs. Now it is a single pass to object code ...

The simple and stupid way for passing parameters between C and assembler is by global variables. It is trivial, it is portable, and independent from possible changes in the calling agreements of the future versions of the same toolset. The aesthetes can implement some sort of locking or roll their own stack to ensure atomic access to globals.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

s used

What embedded target is this for?

X86 AFAIK Borland only did compilers for X86

I don't recall having a single problem with calling agreements breaking down with toolset version. That doesn't seem to be something that changes often -- and I've always been in an environment where we bind a software version to a toolset version, and treat a toolset upgrade as major.

It's certainly a dire thing when the agreement does change, though.

I thought that until recently - but apparently they did others too. We had a request the other day for some other CPU. Although I forget which it was exactly I think it was an old Motorola thing, maybe 68K?

Maybe this has already been written here as I have not read the whole thread, but Borland C 5.5 I think is now (legitimately) free. Paradigm have their own version that is still updated and supported. OpenWatcom have some nice alternative solutions too (not Borland based).

You might want to dig around on our download page..

I know that FC.ZIP

implements an interrupt-driven frequency counter in asm along with a Borland host environment.