The proposal defined 3 types of target sections:
CData IData UData.

I remember that I interpreted CData as "ROM code and data"
but now I think that probably what was meant is just "constant data"
and this type of sections may have no relation to ROM code.
For example, on IIRC AVR the ROM data may reside in the 1st 64K
segment, while the code may be in the code memory above 64K
(that memory is execute-only anyway).

But I *have to specify the target memory map* before compiling any
target code. I have to specify where the code must be located.

Questions:
How this should be done in the dpStandard-compliant way?
How this is done on MPE and FORTH Inc's compilers?

((
My current solution that works well on the current board is:

$0000 $Cfff CDATA SECTION allcrom
' allcrom   IDATA ALIAS-SECTION alliram
' alliram   UDATA ALIAS-SECTION alluram

but this would not work on, say, 8051.
))

((
The goal of standardizing SECTION is not portability
of unchanged sources, as the digits are board-dependent anyway;
the goal is readability and portability of slightly changed sources.
In this regard, specifying code locations is not any worse than
specifying data locations.
))

Does anyone have a link to the proposed standard?

I think CData IData UData refer to how data is treated, not where code
gets compiled to. If you say IDATA and : FOO blah blah ; FOO will
still be a word in ROM.

If you CREATE a table, it might be a ROM table or it might be an
initialized RAM table. The compiler generates startup code to
initialize Idata using a table in ROM, but this is generally
transparent to the user.

A CREATEd table of ROM data is limited to one cell of address data.
IMHO, this limitation is becoming an issue as more and more 16-bit
microcontrollers are available with over 64K of code space. They
usually have ten times more RAM than ROM. 16 bits will cover RAM and
port addresses with no trouble. Not so with the ROM.

You could extend your 16-bit Forth to get over the 64K limit. For
example, PCREATE could define a word that returns a 32-bit code

32-bit address and fetch from code space.

Any ideas on a wordset for this?

On Fri, 27 Sep 2002 14:20:31 +0400, "Michael L.Gassanenko"

CDATA spaces refer to code areas, basically read/execute.
IDATA refers to read/write space that is automagically
initialised.
UDATA refers to read/write space that is NOT initialised
at cross compile time.

The intention on Harvard targets (e.g. AVR and 8051) is
that CDATA describes the type of the CODE area, and UDATA
and IDATA refer to the RAM space. If you need a third
address space you'll have to invent an xDATA name for
yourself.

In a machine with a single adress space all three types
live in the same address space.

In your example, you don't say whether AVR CDATA addresses
are 16 bit or 8 bit addresses. Assuming that you have 128 kb
Flash that is byte addressed by the cross compiler, you
could define:
$00000 $0ffff CDATA SECTION dataspace
$10000 $1ffff CDATA SECTION codespace
$0000  $00FF  UDATA SECTION reserved
$0100  $07FF  UDATA SECTION initialised
$0800  $0FFF  IDATA SECTION uninitialised

\ Now select one section of each type to be current
codespace initilised uninitialised

Stephen

--

MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

ftp://ftp.forth.com/pub/ANS%20Forth/
Both Word and Acrobat versions; the *text.* versions are normative,
the *app.* versions are explanatory appendix.

CData is intended as code space.  It is possible to put data there,
but data is intended to go in IData or UData.  You are correct that
IDATA doesn't affect how colon behaves, because it normally
compiles to the current CData section.

Right.

We use "E-prefix" words to address extended memory on 16-bit

Cheers,
Elizabeth

Most people seem to define memory operators in the form:

where t indicates the type/size and s indicates the
address space or format. For example the following
are common in cross compilers:

and for accessing serially connected data flask, we
might use:

The common form for words using a 32 bit address on
a 16 bit system was:

although with segmented x86 systems the common stack
representation was with the offset on the top of the

Stephen

--

MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

Very good!

But the name is a bit confusing then.
What it was intended to stand for?
Why 'Data'?

On Sun, 29 Sep 2002 11:21:35 +0400, "Michael L.Gassanenko"

Because the initial concepts were thrashed out on a whiteboard
under severe time pressure. And of course there's data in code
space.

Stephen
--

MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads