FORTH in C
chris
How does one create the data structure of a FORTH dictionary entry in C
when it has to be in ROM, not in RAM?
chris in napa
Darin Johnson
> How does one create the data structure of a FORTH dictionary entry in
> C when it has to be in ROM, not in RAM?
There's no standard way to do this in C. You have to rely upon
compiler extensions and provide specifications to the linker.
Most C compilers for embedded systems have some sort of support for
this. So the answer is: check the manual for your compiler and
linker.
--
Darin Johnson
My shoes are too tight, and I have forgotten how to dance -- Babylon 5
rickman
>
> chris <mwa...@sbcglobal.net> writes:
>
> > How does one create the data structure of a FORTH dictionary entry in
> > C when it has to be in ROM, not in RAM?
>
> There's no standard way to do this in C. You have to rely upon
> compiler extensions and provide specifications to the linker.
> Most C compilers for embedded systems have some sort of support for
> this. So the answer is: check the manual for your compiler and
> linker.
I'm not sure this is so hard. In C you can access the base metal by
using type casting and unions (IIRC). If he is implementing an indirect
threaded forth, he can declare an array of pointers (doesn't matter to
what) and stuff the appropriate address into it. At execution time it
won't care if this address is to code or to another part of the list,
the inner interpreter will deal with that.
The inner interpreter can be written in C by using type casting to
execute or to cascade another lookup as appropriate.
--
Rick "rickman" Collins
rick.c...@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Darin Johnson
> I'm not sure this is so hard. In C you can access the base metal by
> using type casting and unions (IIRC).
But you can't directly tell the compiler to put data into RAM or ROM,
which is what the question was.
--
Darin Johnson
Caution! Under no circumstances confuse the mesh with the
interleave operator, except under confusing circumstances!
Trey Boudreau
> rickman <spamgo...@yahoo.com> writes:
>
>> I'm not sure this is so hard. In C you can access the base metal by
>> using type casting and unions (IIRC).
>
> But you can't directly tell the compiler to put data into RAM or ROM,
> which is what the question was.
>
char const * const string = "ROMable text.";
A smart enough compiler knows it can leave string in ROM, whereas:
char * varstring = "mutable text";
must eventually reside in RAM.
In reality, both Forth and C compilers rely on the program loader to
deal with initialized variables. Forth doesn't have any magic bullet
here.
-- Trey
Anton Ertl
> char * varstring = "mutable text";
>
>must eventually reside in RAM.
The pointer must reside in RAM, but the string need not; indeed, gcc
puts the string into a read-only section by default.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
EuroForth 2004: http://www.complang.tuwien.ac.at/anton/euroforth2004/
Deadline (refereed): August 28, 2004; Conference: November 19-21, 2004
Joe Knapka
> On 2004-08-20, Darin Johnson <darin_@_usa_._net> wrote:
> > rickman <spamgo...@yahoo.com> writes:
> >
> >> I'm not sure this is so hard. In C you can access the base metal by
> >> using type casting and unions (IIRC).
> >
> > But you can't directly tell the compiler to put data into RAM or ROM,
> > which is what the question was.
> >
> You can give hints, though:
>
> char const * const string = "ROMable text.";
>
> A smart enough compiler knows it can leave string in ROM, whereas:
>
> char * varstring = "mutable text";
>
> must eventually reside in RAM.
IIRC, in standard C, any string literal may be allocated in read-only
memory, whether it is specified to be const or not. So in your
example, writing to varstring may invoke the infamous "unspecified
behavior".
Cheers,
-- Joe
--
"We sat and watched as this whole <-- (Died Pretty -- "Springenfall")
blue sky turned to black..."
... Re-defeat Bush in '04.
--
pub 1024D/BA496D2B 2004-05-14 Joseph A Knapka
Key fingerprint = 3BA2 FE72 3CBA D4C2 21E4 C9B4 3230 94D7 BA49 6D2B
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.
Ed Beroset
> Trey Boudreau <tr...@blob.internal> writes:
>
>
>>On 2004-08-20, Darin Johnson <darin_@_usa_._net> wrote:
>>
>>>rickman <spamgo...@yahoo.com> writes:
>>>
>>>
>>>>I'm not sure this is so hard. In C you can access the base metal by
>>>>using type casting and unions (IIRC).
>>>
>>>But you can't directly tell the compiler to put data into RAM or ROM,
>>>which is what the question was.
>>>
>>
>>You can give hints, though:
>>
>> char const * const string = "ROMable text.";
>>
>>A smart enough compiler knows it can leave string in ROM, whereas:
>>
>> char * varstring = "mutable text";
>>
>>must eventually reside in RAM.
>
>
> IIRC, in standard C, any string literal may be allocated in read-only
> memory, whether it is specified to be const or not. So in your
> example, writing to varstring may invoke the infamous "unspecified
> behavior".
For embedded systems with which I've worked, one typical way of handling
this is to actually have the linker, and not the compiler, determine the
locations. So from C, if we wanted the dictionary strings in ROM, we
could put them into a separate "compilation unit" (C source file) which
could then be placed by the linker wherever we need it.
It's hard to be helpful without getting into the specifics of a
particular toolset.
Ed
Trey Boudreau
> Trey Boudreau <tr...@blob.internal> writes:
>> char * varstring = "mutable text";
>>
>>must eventually reside in RAM.
>
> The pointer must reside in RAM, but the string need not; indeed, gcc
> puts the string into a read-only section by default.
>
Still, my basic point remains: neither language eliminates the
requirement to understand the runtime system.
> - anton
-- Trey
rickman
I think you guys are missing the point. I don't care what type of
section the compiler thinks my goes is in. If I can set the addresses,
I can determine where the code lives in my system. So if I can control
the addresses (by type casting) I can completely control the RAM and ROM
allocation.