Cross-Compiler word set question 
Author Message
 Cross-Compiler word set question

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.
))



Tue, 15 Mar 2005 18:20:31 GMT  
 Cross-Compiler word set question
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?

Quote:

> 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.
> ))



Wed, 16 Mar 2005 02:40:00 GMT  
 Cross-Compiler word set question
On Fri, 27 Sep 2002 14:20:31 +0400, "Michael L.Gassanenko"

Quote:

>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

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



Wed, 16 Mar 2005 00:16:55 GMT  
 Cross-Compiler word set question

Quote:

> Does anyone have a link to the proposed standard?

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

Quote:
> 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.

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.

Quote:
> 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.

Right.

Quote:
> 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?

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

Cheers,
Elizabeth



Wed, 16 Mar 2005 01:09:53 GMT  
 Cross-Compiler word set question

Quote:
>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?

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



Wed, 16 Mar 2005 20:05:23 GMT  
 Cross-Compiler word set question

Quote:

> CData is intended as code space.

Very good!

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



Thu, 17 Mar 2005 15:21:35 GMT  
 Cross-Compiler word set question
On Sun, 29 Sep 2002 11:21:35 +0400, "Michael L.Gassanenko"

Quote:


>> CData is intended as code space.

>Very good!

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

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



Fri, 18 Mar 2005 00:00:45 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. cross-compiler word set questions

2. Word by word cross reference

3. 6808 Cross compiler question...

4. Ada compilers and cross-compilers

5. Compilers Windows NT or Cross Compiler SunSolaris2.5/Windows NT Fortran77

6. Cross-language challenge (- "word" processing

7. Set of words needed to bootstrap a new Forth

8. 16-color-text-ext word set

9. MInimal set of system words

10. the headers word set

11. Vocabulary word set

12. Floating point word set in Forth-83 ?

 

 
Powered by phpBB® Forum Software