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

[robin.pain]

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

[Joona I Palaste]

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

[Richard Bos]

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

[robin.pain]

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

[Jens.Toerring]

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

[Mark A. Odell]

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 ->
--

[robin.pain]

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

[Mark A. Odell]

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 ->
--

[Kevin Easton]

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.

[Chris Torek]

In article <ne********************@tomato.pcug.org.au>
Kevin Easton <[e-mail]> 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 (40°39.22'N, 111°50.29'W) [phone]
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.

[Kevin Easton]

Chris Torek <no****@elf.eng.bsdi.com> wrote:

In article <ne********************@tomato.pcug.org.au>
Kevin Easton <[e-mail]> 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.

[Chris Torek]

In article <ne********************@tomato.pcug.org.au>
Kevin Easton <[e-mail]> 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 (40°39.22'N, 111°50.29'W) [phone]
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.

[Kevin Easton]

Chris Torek <no****@elf.eng.bsdi.com> wrote:

In article <ne********************@tomato.pcug.org.au>
Kevin Easton <[e-mail]> 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.

[robin.pain]

Kevin Easton <[e-mail]> 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

[Richard Bos]

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

[Dan Pop]

In <bl**********@elf.eng.bsdi.com> Chris Torek <no****@elf.eng.bsdi.com> writes:

In article <ne********************@tomato.pcug.org.au>
Kevin Easton <[e-mail]> 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

[E. Robert Tisdale]

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.