(rickman wrote:
> I am working on an entry for the Luminary Micro Stellaris design
> contest. The contest rules require you to use the the Keil tools that
> come with the LM eval board. This limits the entries to C programs.
Of course, you could implement a Forth in C...
> I started with a Forth program and converted it to C. This went
> without too much trouble and the conversion was fairly easy. I did
> find it a bit harder to debug under C using a standard debugger, but
> there were not many issues that could not be resolved without too much
> pain. Mainly it was a lot easier in Forth to test each word or
> routine separately rather than as part of a whole. The C debug tools
> just don't make it easy to test routines separately.
I don't know what debugger you use, but what I typically do in my C
development is to create a Forth-like shell where every C function is
exposed. So if I had a function like this:
int subtract(int x, int y) { return x - y; }
I could interactively test it from my shell like this:
1 2 subtract .
Which would produce "-1". Depending on the specifics of the target, I
either create a "shim" function that handles the impedance mismatch
between the Forth-like stack and C's call/return, or I do it all at
run-time. This is all based on information extracted from the C
compiler's debugging output and is completely automatic.
> I was using the "Locals" watch window for most of the variables since
> this was automatic. But once in awhile some of the local variables
> would seem to take on absurd values. I could not find anything in my
> code that was doing it. I dug into the disassembly listing and found
> that local variables and the parameter passing was being done in
> registers rather than on the stack.
That's not unusual for small micros. Several of the 8-bit C compilers
I've used use registers to pass arguments to and from functions.
Normally, this is a win in terms of performance, since pushing and
popping arguments off the stack is usually slower. I've also seen C
compilers that use "compiled stack" techniques, where a call-graph
determines the lifetime of functions and allows a stack to be replaced
with absolute RAM locations.
There are obvious limits to both techniques, and it is assumed that the
C programmer understands those limits. For example, "compiled stack"
means that you can't have recursive functions. But if your application
doesn't need recursive functions, that's not a big deal. If it does,
then find the compiler switch that turns off that optimization and live
with the performance hit of a more conventional call/return on a stack.
> All in all I am not a fan of the Keil tools at this point and I don't
> think I am very happy with embedded C development. I have done tons
> of embedded development in the past and I never realized how limited
> the tools were. I always thought of the problem as being an
> unavoidable part of the development process. Factoring code to small
> routines and testing them interactively is so much easier to debug and
> in Forth is so much easier to write.
I have no experience with the Keil tools. I do have a lot of experience
with embedded development using C, and while I can certainly agree that
Forth makes it *easier*, that doesn't mean that the habits one develops
as a Forth programmer can't be applied to C.
Take factoring for example. The way some people here write, the moment
they start coding in C, some mysterious force compels them to write bad
code. Where in Forth they might write small definitions, when faced
with C, suddenly their best instincts fly out the window, and they have
200-line functions.
When I push and try to understand where this comes from, the most
commonly cited reason is "it just takes so much more effort to create a
new function in C. I guess what they are really saying is they don't
comment their Forth words, because the effort to create a stack effect
diagram for each factored word is much like the effort used to create a
function prototype.
Of course, I don't think that's completely it. More often than not when
I see Forth programmers here post C code, it is *bad* C code. It's
usually little things-- unnecessary casts, not using typedef properly,
not understanding common C idioms, etc.-- but those little things add up
to some really bad code.
> The contest rules say the submission has to be done using the Keil
> tools. But that does not mean I have to use the tools while I am
> debugging. I have access to the IAR tools, but I don't know that the
> eval board is supported with these tools. Anyone know if there is a
> board support library for the LM3S811 eval board under IAR?
I don't know the specifics of your platform, but if you find the tools
you're using are too painful, why not just implement a Forth (or some
reasonable subset of Forth) in C. Use C for what it was designed fo
--
a portable assembly language. Use it to code your Forth, and use it for
any timing sensitive code (like interrupt routines).
