Does it possible to use local C-vars in "#pragma asm" block?

>look up OVERLAYABLE in the manual

Thank you for hint, I have read the documentation and have learned something about naming of segments of automatic variables. But I still can't figure out how to use it. I suspect it's impossible ...

Alex.

>look up OVERLAYABLE in the manual

Thank you for hint, I have read the documentation and have learned something about naming of segments of automatic variables. But I still can't figure out how to use it. I suspect it's impossible ...

Alex.

Well, I always says that it's best to keep your assembler in assembler modules, and call them from 'C'.

Most requests seen about inline assembler rely upon risky (or even completely false) assumptions about what can be relied upon from the surrounding 'C'...

But, if you really must do it, you will need to look at the .SRC file generated by the compiler - that will tell you what symbol names are actually being used internally.
(after all, that's what the Assembler is actually seeing...)

Remember, using #pragma ASM effectively just pastes your text into the generated .SRC
A bit like a #include.

See: http://www.keil.com/support/man/docs/c51/c51_asm.htm

Well, I always says that it's best to keep your assembler in assembler modules, and call them from 'C'.

the issue is "do you want to fight your way through or just do it"..The real *** with #pargma asm is that the entire module must be debugged in assembler. OK, do it and then - have fun

Erik

"The real *** with #pargma asm is that the entire module must be debugged in assembler"

Yes, that's true.

So, given that you have to study the assembler in the .SRC file, and you have to debug it in assembler, where is the advantage in having it inline in a 'C' file?!

That's the other reason not to do inline assembler - specifically in C51

Thanks both of you for the response.

it's best to keep your assembler in assembler modules, and call them from 'C'

Agreed. But sometimes external assembler subroutine is too expensive (parameters, call/ret) and not appropriate for small local problem. I use inline asm for more effective bit operations and optimization of loops. Additional benefit is "all code in full view" (no additional files).

look at the .SRC file generated by the compiler - that will tell you what symbol names are actually being used internally.

OK, done. Not so good, compiler creates internal names like 't?040' by unclear rules and changes suffix when I add another variable in {} block. It just that I name "impossible to use"...

Alex.

"sometimes external assembler subroutine is too expensive (parameters, call/ret)"

In that case, particularly given all the other issues already noted with C51 inline assembler, expand the assembler part to a suitable extent where the overhead is no longer significant!

"I use inline asm for more effective bit operations"

In what way do you find the C51 implementation of bit operations ineffective?

"Additional benefit is "all code in full view" (no additional files)."

That's not exactly true: there is an additional file - it's the .SRC file. And this is the one you have to use for debug

In what way do you find the C51 implementation of bit operations ineffective?

Not C51 but limitations of bitwise operations in C (for example, there is no circular shift).

Alex.

Not C51 but limitations of bitwise operations in C (for example, there is no circular shift).

Actually, in C51 there is. Go look up _crol_ and friends in the manual.