On Jan 29, 6:58 pm, John Passaniti
JapanIsShinto.com> wrote:>> 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.
I understand what they are doing and why. But they don't communicate
this info to the debugger for the watch window!
>> 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.
It makes it a bit easier since you don't have to type all the type
definitions of everything on the stack. When you have a lot of "const
unsigned long" data types, this gets very verbose.
> 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.
You can say "bad code", but I am finding my routines in C are much
larger than in Forth. In Forth there was often a minimum size due to
the difficulty of factoring code in nested loops and such. But
otherwise it is just a few extra key strokes to factor out some code
into some logical sub block. In C I find that not having to use the
stack allows me to keep more code together and it will still be
understandable without the mess of stack notation. So I can have a
routine with 10 or 12 lines and it is not a can of worms. The only
real downside it not being able to test the function easily.
I can't say I understood your description of how you emulate a Forth
interface in your main. I assume this would require a simple parser
and be a fair hunk of code. Even if it is just a very simple parser,
the case statement to call all the functions would be huge. Are you
saying you can coax the compiler or linker to sort some of this out?
> 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.
I don't agree. I don't like being verbose in these groups, but I'll
post a code segment. You will see below that the variable definitions
are much more verbose than the placeholders you see in Forth and there
is a lot in this routine that can not be factored out easily. In
Forth I could easily factor out the first IF statement since all the
variables are just parameters on the stack. To do this in a C routine
I would have to pass them all by address and not by value. I have a
strong preference to avoid that sort of thing.
Actually, when I looked a bit harder at the code I found several ways
to improve the factoring. I guess the limitations of the stack really
do force you to consider factoring under Forth much more so than in
C. In C you can run along blissfully unaware that you could take
another look at the code and make it simpler and cleaner while in
Forth the difficulty of following the flow with too many stack
manipulations practically requires you to factor to keep the stack
context limited.
> 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.
Maybe I won't post my C code, I don't want it labeled as "bad" and I
don't think it is a good example of what I was saying. :^(
>> 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 for--
> a portable assembly language. Use it to code your Forth, and use it for
> any timing sensitive code (like interrupt routines).
Because I don't have the time to do that. Last week I took a look for
Forths that support the Cortex M3 processor or were in C form to allow
it to be ported using the C compiler and came up empty handed. At
work I am exploring the possibility of paying one of the two major
Forth vendors to port to the Cortex M3 CPU. Both have come up with
reasonable quotes and I just need to work up my justification. It
can't be based on efficiency of software coding since I am not allowed
to develop software. So this will be for hardware test and debug with
the emphasis on debug.
