Trying to compile a project that uses assembly language.

[Elena]

Hi,

I am trying to compile a project where one of the files uses assembly languange. I don't have much experience with projects. I have usually written single file programs, so all of this is new. Also, I use Turbo C++ 3.0, which lets you make the .exe file from the IDE. The code I have that I downloaded has a make file, but I am not sure how to use it. (need help here, too)

Anyway, the problem is occurring in one of the files which has some assembly code. The error code from the compiler is pretty vague, "Expression syntax", but the line of code and the surrounding code look OK.
The line is :
asm .386

Can someone point me in the right direction? I've been working on this for a couple of weeks, with no luck on my own.

I guess the time for learning out of books is over. I'll have to take a class.

Thanks,

 

[adholioshake]

The .386 is actually a macro not an assembly language opcode. It is usually used at the start of an assembly program to tell the assembler it is designed for 386+ processors (e.g. can use 32-bit registers).

The borland compiler probably doesn't like you using macros like this from within the C program, as the linker/compiler sets this according to the memory model and other details you select from the linke settings menu.

I think you will probably be safe leaving the .386 out anyway, as most C programs are geared for 386+ processors.

To be anymore help to you, I would need to see the C and/or assembly code to see what you are trying to do.


The mind is like a parachute - it works better when open...

 

[Elena]

Actually, I figured it out. It turns out that I need Turbo Assembler to compile this. The inline assembler can't handle macros. I have to purchase Turbo Assembler separately. Bummer for me, because it is $140.00. Too bad Borland doesn't include this in their antique software section.

Anyway, thanks for the help.

Elena

 

[zeitghost]

Can you post the function with the assembly in it on here?

Gives us a chance to play around with it and come up with a cunning plan or two.

rgds
Zeit.

 

[lionelhill]

Don't go buying things before you've worked out you need to. The inline assembler may not do everything that a "real" assembler does, but it will do it directly inline. As written above, things like .386 (which isn't a real macro, it's just a directive telling the assembler how to behave) are not necessary in an inline environment because compiler directives will already take care of such options. For instance, in the good old days of dos, I used to use the inline assembler in turbo pascal a lot. It didn't need .286 because you set 286 code on or off for the compiler itself, and that logically carried over to the inline assembler. The inline assembler Won't handle the more devious niceties of a real assembler (specifying memory model, writing macros etc.) Because the compiler itself provides alternatives that are more elegant. The inline assembler Will write a reasonably full repertoir of genuine code.

It's far more likely you'll run into problems with the assembly code not integrating properly with the C code, or using the wrong memory model or whatever (doing things an operating system doesn't like). Using the inline assembler saves you a lot of grief in this direction. I'd strongly recommend going inline if you can.

But I might be writing rubbish.

 

[zeitghost]

Sounds sensible to me lionelhill.

I've had interesting times trying to port some win3.1 apps from the MS compiler to the Borland compiler.

Took me weeks to figure out one peculiarity.

rgds
Zeit.

 

[adholioshake]

You could instead of trying inline assembly write the assembly in a separate file. You can assemble this using TASM, MASM or whatever to get the object file and then link this object file together with your C file.

The assembly code should be written as a function you can call from the C program - you just have to be thoughtful about parameter passing.

 

[Elena]

I actually finally got it to work by using TASM 5.0 with Turbo C++ 3.0. I had to tweak a few things, but ultimately, it worked. I still have to go through the rest of the code to see how my tweaks will affect it, but at least it compiled. Progress is a good thing.

Apparently, the code was written for x386 systems, and Turbo C ++ 3.0 does not support that; it only goes up to x286. Also, there were some problems in the assembly code itself (trying to stick a 32-bit variable in a 16-bit register), at least it was 16 bit for Turbo C++ 3.0.

I would still like to try Borland C++ 4.52 with the original code (now I'm just curious). If anyone know where I can get it (cheap), I would be most grateful for the info.

Thanks,
Elena

 

[lionelhill]

Elena, I'm impressed.
Where you have inline 16-bit code and are limited to 286 instructions with no 32-bit stuff, but you know you have a 32bit processor, you can sometimes still use 32-bit registers. What you need to do is write the segment size override prefix, which I think offhand is 066h (but for goodness sake check that! my memory is not good) as a db before the instruction it should affect. Then you write it as though it were 16bit
e.g.
db 066h
mov ax, bx
will actually execute as mov eax, ebx.
This is evil but has got me out of a corner once...
Best wishes,
Li

 

[zeitghost]

And if you do that, be sure to comment it like

db 066h ;32 bit segment override prefix

or in about 3 weeks time you'll have forgotten what it means if you have a memory like mine.

rgds
Zeit.

 

[lionelhill]

Couldn't agree more.