Turbo C Help

[paolomontero]

Hi,

Im new to this forums. Im trying to code in Turbo C 2.01 or Turbo C++ 1.01. Im using either of these compilers because they output 16 bit code.

But im stuck with a problem, both with Turbo C and Turbo C++.

I've reduced it to the following. My code is:


void f(char *);

char h[] = "hello";

void main() {
f(h);
}

void f(char *s) {
int n = 0;
while (s[n] != 0) {
/*do something*/
n++;
}
}


It's just a function that takes a string as an argument and merely loops till it finds the terminating NULL character.

I compile it like this (the file is named c.c):

tcc -mt c.c
tlink C.OBJ

and then i do exe2bin C.EXE to get the raw binary image.

The disassembly for either the .bin or .exe (they are the same, but it's easier to work with the .bin because it doesn't have the "turbo c junk code") is the following:


0000 mov ax, 000E
0003 push ax
0004 call 0009
0007 pop cx
0008 ret
0009 push bp
000A mov bp, sp
000C push si
000D xor si, si
000F jmp 0012
0011 inc si
0012 mov bx, [bp+04]
0015 cmp byte ptr [bx+si], 00
0018 jne 0011
001A pop si
001B pop bp
001C ret
001E 'hello\0' ;you get me :)



So, the problem is the first line!

mov ax, 000E

It doesn't point to the string, which is located in 001E, so if i change that byte with a hexadecimal editor the program works just fine.

My question is: why does Turbo C commit this error? Am i doing something wrong?

NOTE: if the function f has no code then the address is correctly compiled, but if it as ANY code, like a variable declaration, then the problem appears.

Thanks

[mbbrutman]

I'm a Turbo C++ 3.0 user. I can't answer your questions directly, but maybe we can get closer.

The code is correct, but I'm confused about why you are using exe2bin. Is that just to make the disassembly easier to read? If you compiled the code using the 'small' memory model then that is legal.

One thing that you might be missing is that the stack segment might be one paragraph different than the code segment. If you run it under debug and see that SS is different than CS by one paragraph, that will confirm it.

I love Turbo C++ 3.0. It's missing some language features (like 'new' with placement'), but it's been rock solid. Every time I thought I had a bug in the compiler code gen, it's actually been my fault.


Mike

Hi,

Im new to this forums. Im trying to code in Turbo C 2.01 or Turbo C++ 1.01. Im using either of these compilers because they output 16 bit code.

But im stuck with a problem, both with Turbo C and Turbo C++.

I've reduced it to the following. My code is:


void f(char *);

char h[] = "hello";

void main() {
f(h);
}

void f(char *s) {
int n = 0;
while (s[n] != 0) {
/*do something*/
n++;
}
}


It's just a function that takes a string as an argument and merely loops till it finds the terminating NULL character.

I compile it like this (the file is named c.c):

tcc -mt c.c
tlink C.OBJ

and then i do exe2bin C.EXE to get the raw binary image.

The disassembly for either the .bin or .exe (they are the same, but it's easier to work with the .bin because it doesn't have the "turbo c junk code") is the following:


0000 mov ax, 000E
0003 push ax
0004 call 0009
0007 pop cx
0008 ret
0009 push bp
000A mov bp, sp
000C push si
000D xor si, si
000F jmp 0012
0011 inc si
0012 mov bx, [bp+04]
0015 cmp byte ptr [bx+si], 00
0018 jne 0011
001A pop si
001B pop bp
001C ret
001E 'hello\0' ;you get me :)



So, the problem is the first line!

mov ax, 000E

It doesn't point to the string, which is located in 001E, so if i change that byte with a hexadecimal editor the program works just fine.

My question is: why does Turbo C commit this error? Am i doing something wrong?

NOTE: if the function f has no code then the address is correctly compiled, but if it as ANY code, like a variable declaration, then the problem appears.

Thanks

[paolomontero]

Mike, thanks alot for replying and also very fast.

Im glad to see that there are others that also use legacy compilers because i havent been getting much support in other forums.

Is that just to make the disassembly easier to read?

Thats exactly why i do it. Im not using small memory model, thou, im using tiny, but i really dont know what the difference is.

Im not sure how to check what you said using debug. I loaded the file using -n for the path and then -l, then -r to see the registers. If thats what you meant then SS is the same as CS.

If you want i can send you a copy of bin file (since you cant compile it) either by email or i can upload it to some server; if you have the time and you want, of course.

This is really driving me insane, ive been trying to solve this for over 2 weeks now. Youve given me the first possible solution, but anyhow i dont know how to fix it if that was the problem.

Gabriel

[mbbrutman]

I'm travelling for business so I don't have Turbo C++ handy at the moment. I won't be able to get to it until Sunday or Monday. But send me the code and the exe (not the bin) and I'll play with it and see if I get the same results. (My email addr is available in my user profile here - just click on my name.)

I get confused between tiny and small. You want the one that is at the top of the list if you are going to make a COM file. It's probably tiny.

[Trixter]

Im not sure how to check what you said using debug. I loaded the file using -n for the path and then -l, then -r to see the registers. If thats what you meant then SS is the same as CS.


[bx+si] assumes DS. Does DS = SS = CS? If not, you can't make the assumptions you're making about your binary image.

I think you should compile for a .COM, load the .COM into Turbo Debugger, then step through your program so you can figure out what's going on. I think that your EXE2BIN process is borking the offsets or something.


If you want i can send you a copy of bin file (since you cant compile it) either by email or i can upload it to some server; if you have the time and you want, of course.


I'd rather see the .com or .exe, actually.

[paolomontero]

The compiled exe and the binary image of exe2bin are the same, i had checked that with td. Also, when stepping with td there is nothing wrong, the address of the char array is just wrongly compiled (because im doing something wrong, of course).

I cant output a com file, when i do:

tcc -mt -c source.c
tlink source.obj /t

I get a linker error:

"Cannot generate COM file : invalid initial entry point address"

I dont know how to set the entry point to 100h in Turbo C.

The code i use is posted in my first message. I have to compile like that (and not in one step) because im using assembly obj files too.

Gabriel,

[chuckcmagee]

As explained, you really need to see if DS & CS are the same value in td.