| |
In lugnet.robotics.rcx.legos, Michael Purvis wrote:
> In lugnet.robotics.rcx.legos, Mark Riley wrote:
> > Also, if you're going to use inline assembly code, the compiler needs to be
> > aware that variables can be changed by your code. One way is to declare the
> > total variable as "volatile" like so:
> >
> > volatile unsigned char total;
>
> Oh, I see. That's nifty. So a 'volatile' keyword ensures that it's reloaded
> every time?
Volatile tells the compiler that should assume the value can change without the
compiler's knowledge. So yes, it gets reloaded every time.
>
> > FYI, I believe there are other ways (besides the volatile keyword) to tell the
> > compiler about what your assembly code is doing, but I haven't delved that far
> > into the docs yet (look under the __asm__ keyword for more info).
>
> Which doc is this? The only ones I have are the BrickOS command reference (it's
> a shorter HTML one), and the software manual from Hitachi.
To find this stuff, you need to read through documentation for GCC. It has been
a few years since I worked on embedded systems. This topic is not specific to
BrickOS, but instead specific to GCC.
>
> > BTW, Kevin's suggestion of using the "-S" option with gcc is a good one, you can
> > learn a lot about H8 assembly just by seeing what the C compiler produces (you
> > can also learn what *not* to do! ;-) A simple way to get the source file is to
> > type "make program.s" if your program is named program.c (I think you'll have to
> > modify the Makefile if you're using C++, though).
>
> Yeah, I'll check that out. I couldn't get it to work when I tried it at first,
> but I'll give a more sustained attempt tonight.
You might have to make a new rule to convert .c files to .s files by compiling
with the -S option.
Try adding the rule below into Makefile.common
# how to generate an assembly listing of a C source
%.s: %.c
$(CC) $(CFLAGS) -c $< -S
Then you can type:
make mycode.s
If there is a mycode.s you will get a .s file that you can edit and examine.
>
> One final thing is about accessing local variables. I didn't have a problem
> using offsets on a global array, but what about a local one? I could change the
> structure of my program so that all the vars that need to be accessed in this
> way are globals, but it would be much more straight forward to do it this way.
> Particularly since the specific procedure is part of a recursive function.
Local variables exist in registers or on the stack. Your array would be on the
stack for sure, so you are going to have to do stack relative addressing, by
knowing which register is the C call stack pointer.
>
> Mike
Kevin
|
|
Message is in Reply To:
 | | Re: BrickOS Assembler
|
| (...) Oh, I see. That's nifty. So a 'volatile' keyword ensures that it's reloaded every time? (...) Which doc is this? The only ones I have are the BrickOS command reference (it's a shorter HTML one), and the software manual from Hitachi. (...) (...) (20 years ago, 20-Jan-04, to lugnet.robotics.rcx.legos)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
