#include<stdio.h>
int cauta(int near *a, size_t n, int x)
{
asm{
push si
push cx
push dx
mov si, a
mov cx, n
jcxz not_gasit
mov dx, x
sub si, 2
}
reluare:
asm{
add si, 2
cmp [si], dx
loopnz reluare
jnz not_gasit
mov ax, n
sub ax, cx
dec ax
jmp final
}
not_gasit:
asm mov ax, -1
final: asm{
pop dx
pop cx
pop si
}
return _AX;
}
int main()
{
int a[100];
a[0] = 4;
a[1] = 5;
a[2] = 1;
a[3] = 9;
printf("%d", cauta(a, 4, 1);
}
The problem is that I get some errors:
1 2 3 4 5 6
D:\C++ Projects\Preparing for ONI\main.c|4|error: expected ';', ',' or ')' before '*' token|
D:\C++ Projects\Preparing for ONI\main.c||In function 'main':|
D:\C++ Projects\Preparing for ONI\main.c|49|warning: implicit declaration of function 'cauta'|
D:\C++ Projects\Preparing for ONI\main.c|49|error: expected ')' before ';' token|
D:\C++ Projects\Preparing for ONI\main.c|50|error: expected ';' before '}' token|
||=== Build finished: 3 errors, 1 warnings ===|
It looks like the compiler didn't recognize the near keyword on line 4. The near keyword is a throwback to 16 bit memory architectures and is obsolete on 32 bit machines. That also caused your function call not to be recognized on line 49.
If you truely need the near keyword, you should check your compiler documentation. There may be a compile time switch to enable it, or it might be _near depending on the implementation, if it's supported at all.
I was going to suggest:
1. rewrite the C version using pointers rather than array indexing.
2. get the compiler to output intermediate asm code, which you can then borrow for getting the appropriate syntax.
3. tweak or replace the generated code as required.
Chervil: I tried to do that a few months ago, but the output code is absolutely understanable. For a simple Hello World program, I get over 500 lines of ASM code. I don't really know if that is ok...
AbstractionAnon: I didn't create that function in ASM. As I said below, I found it in a book, and I just copied it in the Code::Blocks environment to see if it works. So the "near" keyword belongs to the implementation found in that book.
For a simple Hello World program, I get over 500 lines of ASM code. I don't really know if that is ok...
That's not normal at all. You might be seeing a bunch of boilerplate code in there, but for a hello world program, the code that actually outputs should only be a few lines.
What I did was create a simple function, such as "add two integers and return the result". But I gave the function and variables very distinctive names. That way, it was very easy to identify the relevant part of the code, and I ignored the rest.
Allright, but if you don't really know the ASM syntax, I think that is very difficult to consider just a part of that code. I mean...what if you miss some very important instruction, for instance to clear the memory or something like that?
It will all be grouped together. The boilerplate will be in front and behind it. Grab a manual for your given architecture and use that as a reference.
I don't know, I suggested using the code generated by the compiler precisely to avoid such problems. If that approach doesn't work for you, that's fine too.
Are you doing this to learn asm, or are you doing this because you think you can write a more efficient find loop than C?
Frankly, with today's optimizing compilers it is hard to write something more efficient than what the compiler generates with the highest optimization level.
Did you compile in debugging mode? Release mode should give more compact code.
The name of the function "add" isn't particularly distinctive - rather the opposite.
Still, I don't wish to waste your time with this if it isn't proving fruitful.