By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,480 Members | 1,164 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,480 IT Pros & Developers. It's quick & easy.

IAR, __ASM(), and *.s33 to *.C files

P: n/a
Inlining assembler in a *.c file:-

Both

__asm("nop \n")

and

__asm("nop")

work

I have abandonned using __asm() it because it only seems to accept a
literal string. Trying to pass it an <unsigned char*> as the manual
suggests fails with a syntax error. Also as a last resort I tried
this:-

__asm ("ldaa SC1SR1")
__asm ("std SC1DRH")

but it failed with a "unknown variable or function identifier".
Despite the proceeding:-

#include <r812a4.h>

That contains SC1SR1 etc. It only works if you avoid labels entirely
e.g.

__asm ("ldaa 0xCC")
__asm ("std 0xCD")

Which is asking for it! "I didn't get where I am today by..." as the
famous Rigsby used to say.

What I have opted for is to add a *.s33 file to the project containing
the assembler [and my beloved macro that I originally intended to pass
to the __asm ( ) ]:-

//****************.s33 file *********************
$equates.equ

RSEG RCODE //Root-Code: assemble in common or
shared rom
public init_sci_and_send_a_percent

....
init_sci_and_send_a_percent
ldaa SC1SR1 //step 1 of clear pending data
interrupts
std SC1DRH //step 2 of clear pending data
interrupts
aux_tx '%' //send an % char from RS232
rtc

END
//****************end of *.s33 file***************

And then calling if from the *.c file

//****************.c file ************************
extern init_sci_and_send_a_percent
....
init_sci_and_send_a_percent();
//**************end of *.c file*******************

It is easy to mix and match *.s33 and *.c files but only the crudest
inlining is possible and only by breaking the one definition rule. At
the very least we should be able to inline a macro that's the whole
point!

Robin
Nov 13 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
ro********@tesco.net <ro********@tesco.net> scribbled the following:
Inlining assembler in a *.c file:-


....is entirely system-specific and therefore off-topic on
comp.lang.c.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen
Nov 13 '05 #2

P: n/a
ro********@tesco.net (ro********@tesco.net) wrote:
Inlining assembler in a *.c file:-


Stop right there.

Inlining assembly is not only not ISO Standard C, it is arguably the
single most system-dependent function your compiler may (or may not)
have. You really need to ask this in a compiler-specific newsgroup.

Richard
Nov 13 '05 #3

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<3f****************@news.nl.net>...
ro********@tesco.net (ro********@tesco.net) wrote:
Inlining assembler in a *.c file:-


Stop right there.

Inlining assembly is not only not ISO Standard C, it is arguably the
single most system-dependent function your compiler may (or may not)
have. You really need to ask this in a compiler-specific newsgroup.

Richard


Ok ok I stop. Don't you guys ever get your hands dirty?

Robin
Nov 13 '05 #4

P: n/a
ro********@tesco.net <ro********@tesco.net> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<3f****************@news.nl.net>...
ro********@tesco.net (ro********@tesco.net) wrote:
> Inlining assembler in a *.c file:-
Stop right there.

Inlining assembly is not only not ISO Standard C, it is arguably the
single most system-dependent function your compiler may (or may not)
have. You really need to ask this in a compiler-specific newsgroup.

Richard

Ok ok I stop. Don't you guys ever get your hands dirty?


We do, but we wash them before having dinner ;-)

Regards, Jens
--
_ _____ _____
| ||_ _||_ _| Je***********@physik.fu-berlin.de
_ | | | | | |
| |_| | | | | | http://www.physik.fu-berlin.de/~toerring
\___/ens|_|homs|_|oerring
Nov 13 '05 #5

P: n/a
ro********@tesco.net (ro********@tesco.net) wrote in
news:bd**************************@posting.google.c om:
> Inlining assembler in a *.c file:-
Stop right there.

Inlining assembly is not only not ISO Standard C, it is arguably the
single most system-dependent function your compiler may (or may not)
have. You really need to ask this in a compiler-specific newsgroup.

Ok ok I stop. Don't you guys ever get your hands dirty?


Yes, but we do it in comp.arch.embedded! Come on over and re-post.

--
- Mark ->
--
Nov 13 '05 #6

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...
ro********@tesco.net <ro********@tesco.net> scribbled the following:
Inlining assembler in a *.c file:-


...is entirely system-specific and therefore off-topic on
comp.lang.c.


(Ouch) it's (oww) not for you boss (oof) this is for a fellow
low-grade trying to iterate their way from a hybrid assembler/C to
pure C. (phew)

Robin
Nov 13 '05 #7

P: n/a
ro********@tesco.net (ro********@tesco.net) wrote in
news:bd**************************@posting.google.c om:
> Inlining assembler in a *.c file:-


...is entirely system-specific and therefore off-topic on
comp.lang.c.


(Ouch) it's (oww) not for you boss (oof) this is for a fellow
low-grade trying to iterate their way from a hybrid assembler/C to
pure C. (phew)


Nonetheless, it's still an off-topic question. I await your post in
comp.arch.embedded where it is topical.

--
- Mark ->
--
Nov 13 '05 #8

P: n/a
ro********@tesco.net <ro********@tesco.net> wrote:
Inlining assembler in a *.c file:- [...] I have abandonned using __asm() it because it only seems to accept a
literal string. Trying to pass it an <unsigned char*> as the manual
suggests fails with a syntax error. Also as a last resort I tried
this:-
(<OT> Well "duh" - there isn't a runtime assembler included in your
program you know...</OT>)

I think there's actually a standard C question here:
__asm ("ldaa SC1SR1")
__asm ("std SC1DRH")

but it failed with a "unknown variable or function identifier".


I'm guessing SC1SR1 and SC1DRH are macros defined in the header file you
mention. Macros aren't expanded inside string literals - but if those
macros expand to string literals, then you can use the fact that
adjacent string literals are concatenated:

__asm ("ldaa " SC1SR1)
__asm ("std " SC1DRH)

- Kevin.

Nov 13 '05 #9

P: n/a
In article <ne********************@tomato.pcug.org.au>
Kevin Easton <kevin@-nospam-pcug.org.au> writes:
I think there's actually a standard C question here ...
Macros aren't expanded inside string literals - but if those
macros expand to string literals, then you can use the fact that
adjacent string literals are concatenated:

__asm ("ldaa " SC1SR1)
__asm ("std " SC1DRH)


This is indeed likely to work (it does in GCC for instance), but
there is no guarantee that anything following a compiler-specific
keyword like __asm is going to be treated lexically or syntactically
like C code. So it could fail. The answer should be in the
compiler's documentation; if not, the "try it and see" method is
always available, however flawed it may be. :-)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #10

P: n/a
Chris Torek <no****@elf.eng.bsdi.com> wrote:
In article <ne********************@tomato.pcug.org.au>
Kevin Easton <kevin@-nospam-pcug.org.au> writes:
I think there's actually a standard C question here ...
Macros aren't expanded inside string literals - but if those
macros expand to string literals, then you can use the fact that
adjacent string literals are concatenated:

__asm ("ldaa " SC1SR1)
__asm ("std " SC1DRH)


This is indeed likely to work (it does in GCC for instance), but
there is no guarantee that anything following a compiler-specific
keyword like __asm is going to be treated lexically or syntactically
like C code. So it could fail. The answer should be in the
compiler's documentation; if not, the "try it and see" method is
always available, however flawed it may be. :-)


Hmm. I reasoned that the __asm doesn't introduce undefined behaviour
until after the preprocessing phases of translation are complete,
because until then it's just a pptoken, and it's not a reserved pptoken
(or is it?).

- Kevin.

Nov 13 '05 #11

P: n/a
In article <ne********************@tomato.pcug.org.au>
Kevin Easton <kevin@-nospam-pcug.org.au> writes:
Hmm. I reasoned that the __asm doesn't introduce undefined behaviour
until after the preprocessing phases of translation are complete,
because until then it's just a pptoken, and it's not a reserved pptoken
(or is it?).


Given that __asm starts with a double underscore, it seems to me
that all bets are off. I believe we have existence proofs (in the
form of old x86 C compilers) of "__asm-like" constructs that do
not obey C syntax. But I have no examples.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #12

P: n/a
Chris Torek <no****@elf.eng.bsdi.com> wrote:
In article <ne********************@tomato.pcug.org.au>
Kevin Easton <kevin@-nospam-pcug.org.au> writes:
Hmm. I reasoned that the __asm doesn't introduce undefined behaviour
until after the preprocessing phases of translation are complete,
because until then it's just a pptoken, and it's not a reserved pptoken
(or is it?).


Given that __asm starts with a double underscore, it seems to me
that all bets are off. I believe we have existence proofs (in the
form of old x86 C compilers) of "__asm-like" constructs that do
not obey C syntax. But I have no examples.


You're probably right. I always thought that's what #pragma was for,
though (introducing undefined behaviour during preprocessing).

- Kevin.

Nov 13 '05 #13

P: n/a
Kevin Easton <kevin@-nospam-pcug.org.au> wrote in message news:<ne********************@tomato.pcug.org.au>.. .
ro********@tesco.net <ro********@tesco.net> wrote:
Inlining assembler in a *.c file:-

[...]
I have abandonned using __asm() it because it only seems to accept a
literal string. Trying to pass it an <unsigned char*> as the manual
suggests fails with a syntax error. Also as a last resort I tried
this:-


(<OT> Well "duh" - there isn't a runtime assembler included in your
program you know...</OT>)


(<gagged><OT> urgggg! it's mrghhh! all mrrghhh! statically compiled!
phheww </gagged><OT>

Robin
Nov 13 '05 #14

P: n/a
ro********@tesco.net (ro********@tesco.net) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<3f****************@news.nl.net>...
ro********@tesco.net (ro********@tesco.net) wrote:
Inlining assembler in a *.c file:-


Stop right there.

Inlining assembly is not only not ISO Standard C, it is arguably the
single most system-dependent function your compiler may (or may not)
have. You really need to ask this in a compiler-specific newsgroup.


Ok ok I stop. Don't you guys ever get your hands dirty?


Yes. The blood is damn hard to get rid of, too.

Richard
Nov 13 '05 #15

P: n/a
In <bl**********@elf.eng.bsdi.com> Chris Torek <no****@elf.eng.bsdi.com> writes:
In article <ne********************@tomato.pcug.org.au>
Kevin Easton <kevin@-nospam-pcug.org.au> writes:
Hmm. I reasoned that the __asm doesn't introduce undefined behaviour
until after the preprocessing phases of translation are complete,
because until then it's just a pptoken, and it's not a reserved pptoken
(or is it?).


Given that __asm starts with a double underscore, it seems to me
that all bets are off.


Use the asm keyword instead (as suggested by the standard itself) and
all the bets are on at least until translation phase 8 ;-) If the
compiler doesn't recognise it as a keyword, it must handle it as a valid
function call. It's an ordinary pp-token, as far as the preprocessor is
concerned...

There is little point in compiling such code with the compiler in
conforming mode, anyway.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #16

P: n/a
ro********@tesco.net wrote:
Inlining assembler in a *.c file:-

Both

__asm("nop \n")

and

__asm("nop")

work

I have abandoned using __asm() it because it only seems to accept a
literal string. Trying to pass it an <unsigned char*> as the manual
suggests fails with a syntax error.
Also, as a last resort, I tried this:-

__asm ("ldaa SC1SR1")
__asm ("std SC1DRH")

but it failed with a "unknown variable or function identifier".
Despite the proceeding:-

#include <r812a4.h>

That contains SC1SR1 etc. It only works if you avoid labels entirely
e.g.

__asm ("ldaa 0xCC")
__asm ("std 0xCD")

Which is asking for it! "I didn't get where I am today by..." as the
famous Rigsby used to say.

What I have opted for is to add a *.s33 file to the project containing
the assembler [and my beloved macro that I originally intended to pass
to the __asm ( ) ]:-

//****************.s33 file *********************
$equates.equ

RSEG RCODE //Root-Code: assemble in common or
shared rom
public init_sci_and_send_a_percent

...
init_sci_and_send_a_percent
ldaa SC1SR1 //step 1 of clear pending data
interrupts
std SC1DRH //step 2 of clear pending data
interrupts
aux_tx '%' //send an % char from RS232
rtc

END
//****************end of *.s33 file***************

And then calling if from the *.c file

//****************.c file ************************
extern init_sci_and_send_a_percent
...
init_sci_and_send_a_percent();
//**************end of *.c file*******************

It is easy to mix and match *.s33 and *.c files but only the crudest
inlining is possible and only by breaking the one definition rule.
At the very least we should be able to inline a macro.
That's the whole point!


Hi Robin,

I see that you've already met our "Off Topic Cops".
Please ignore them.

If you can tell us which compiler (and operating system) you are using,
we can probably redirect you to a more appropriate forum.
Subscribers to the comp.lang.c newsgroup don't usually respond
to questions about compiler specific features
but also subscribe to compiler specific newsgroups
and would be more that happy to respond to your questions
if you would only post them in the appropriate newsgroup.

Nov 13 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.