[PicForth] RE: PicForth Digest, Vol 10, Issue 1
Randall Young
rsyoung at tigerpaw.com
Thu Jan 20 17:54:17 CET 2005
Dear David,
Very interested in you F18 Forth compiler, I'm really looking forward to
seeing your Python code for the compiler.
Have you tried Wing-IDE? Great product!
Good luck, and thanks! Can you let me know when it's available?
Regard,
Randy
-----Original Message-----
From: picforth-bounces+rsyoung=tigerpaw.com at lists.rfc1149.net
[mailto:picforth-bounces+rsyoung=tigerpaw.com at lists.rfc1149.net]On Behalf Of
picforth-request at lists.rfc1149.net
Sent: Monday, January 17, 2005 5:00 AM
To: picforth at lists.rfc1149.net
Subject: PicForth Digest, Vol 10, Issue 1
Send PicForth mailing list submissions to
picforth at lists.rfc1149.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.rfc1149.net/mailman/listinfo/picforth
or, via email, send a message with subject or body 'help' to
picforth-request at lists.rfc1149.net
You can reach the person managing the list at
picforth-owner at lists.rfc1149.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of PicForth digest..."
Today's Topics:
1. pre-announcing Forth for PIC18F chips (David McNab)
2. Re: pre-announcing Forth for PIC18F chips (J.C. Wren)
3. Re: pre-announcing Forth for PIC18F chips (David P Harris)
4. Re: pre-announcing Forth for PIC18F chips (David McNab)
5. Re: pre-announcing Forth for PIC18F chips (Mark J. Dulcey)
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 Jan 2005 03:04:25 +1300
From: David McNab <david at rebirthing.co.nz>
Subject: [PicForth] pre-announcing Forth for PIC18F chips
To: gnupic at linuxhacker.org, picforth at lists.rfc1149.net
Message-ID: <41EA7469.7080902 at rebirthing.co.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi gnupic and picforth people,
This is a pre-announcement of a coming Forth compiler for the PIC18Fxxx
chips. I've tentatively called it 'PIC18forth', but am open to
suggestions for a better name.
PIC18forth is radically different from the PIC16Fxxx-only PicForth
compiler. Almost nothing in common, since I've written PIC18forth from
scratch.
Quick summary of features - love them and loathe them:
* signed/unsigned 16-bit data cells and operators
* software return stack
* data stack grows up (increasing addresses), while
return stack grows down (decreasing addresses)
* total allocated size of data+return stacks can
be set to anything between 16 and 1024 bytes
* compiler is written in Python, and is very approachable
and extensible, even for people new to the code
* integrated into gputils
* forth sources get compiled to relocatable assembly (.asm)
sources, ready for gpasm and gplink
* the generated code embeds a 16-bit forth vm (token threaded
execution model) which executes bytecodes
* the generated code is self-contained, and once assembled
and linked, can be downloaded/flashed as a standalone program
* FSR0 is usually used for data stack ptr, FSR1 usually
used as return stack ptr, FSR2 used as general purpose
pointer
* full support for locals (John Hopkins syntax, data
gets transferred from data stack to a frame on return stack
* vm design favours code density over execution speed
* contents of 'code .. end-code' definitions are included
verbatim in generated assembly source (with '\' comments
changed to ';')
* the defining-words 'primitive .. end-primitive' can be
used in place of 'code .. end-code', to define a word
in assembler which will be available as a single-byte
vm instruction - easy to add/remove primitives at will
* maps to von Neumann memory model, with addresses <8000H
treated as RAM addresses, and addresses>=8000H treated
as program ROM addresses
If you're currently hacking with PIC18Fxxx chips, and are interested in
trying out PIC18forth, please mail me and I'll put you on a list for
pre-alpha-testers.
--
Cheers
David
------------------------------
Message: 2
Date: Sun, 16 Jan 2005 09:16:35 -0500
From: "J.C. Wren" <jcwren at jcwren.com>
Subject: Re: [PicForth] pre-announcing Forth for PIC18F chips
To: David McNab <david at rebirthing.co.nz>
Cc: picforth at lists.rfc1149.net, gnupic at linuxhacker.org
Message-ID: <41EA7743.7010109 at jcwren.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Are the von Neuman memory map limits fixed? The PIC18F8621, for
example, has 3K of RAM, and 64K of FLASH. I'd like to be able to use
all the RAM, and 61K of the FLASH.
The '8621 also has a 31 entry hardware stack, with stack underflow
and overflow detection. If it's not too unreasonable, it might be nice
to be able to use that instead of a software stack. For large programs,
it's obviously inadequate, but for a lot of projects it's more than enough.
--jc
David McNab wrote:
> Hi gnupic and picforth people,
>
> This is a pre-announcement of a coming Forth compiler for the
> PIC18Fxxx chips. I've tentatively called it 'PIC18forth', but am open
> to suggestions for a better name.
>
> PIC18forth is radically different from the PIC16Fxxx-only PicForth
> compiler. Almost nothing in common, since I've written PIC18forth from
> scratch.
>
> Quick summary of features - love them and loathe them:
>
> * signed/unsigned 16-bit data cells and operators
> * software return stack
> * data stack grows up (increasing addresses), while
> return stack grows down (decreasing addresses)
> * total allocated size of data+return stacks can
> be set to anything between 16 and 1024 bytes
> * compiler is written in Python, and is very approachable
> and extensible, even for people new to the code
> * integrated into gputils
> * forth sources get compiled to relocatable assembly (.asm)
> sources, ready for gpasm and gplink
> * the generated code embeds a 16-bit forth vm (token threaded
> execution model) which executes bytecodes
> * the generated code is self-contained, and once assembled
> and linked, can be downloaded/flashed as a standalone program
> * FSR0 is usually used for data stack ptr, FSR1 usually
> used as return stack ptr, FSR2 used as general purpose
> pointer
> * full support for locals (John Hopkins syntax, data
> gets transferred from data stack to a frame on return stack
> * vm design favours code density over execution speed
> * contents of 'code .. end-code' definitions are included
> verbatim in generated assembly source (with '\' comments
> changed to ';')
> * the defining-words 'primitive .. end-primitive' can be
> used in place of 'code .. end-code', to define a word
> in assembler which will be available as a single-byte
> vm instruction - easy to add/remove primitives at will
> * maps to von Neumann memory model, with addresses <8000H
> treated as RAM addresses, and addresses>=8000H treated
> as program ROM addresses
>
> If you're currently hacking with PIC18Fxxx chips, and are interested
> in trying out PIC18forth, please mail me and I'll put you on a list
> for pre-alpha-testers.
>
------------------------------
Message: 3
Date: Sun, 16 Jan 2005 10:35:06 -0800
From: David P Harris <dpharris at telus.net>
Subject: Re: [PicForth] pre-announcing Forth for PIC18F chips
To: David McNab <david at rebirthing.co.nz>, picforth at lists.rfc1149.net
Message-ID: <41EAB3DA.3060202 at telus.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
David-
This sounds excellent! Sign me up!
PIC18Forth is descriptive if mundane.
The extensibility sounds very good.
I don't know Python, but know enough languages that it shouldn't be too
big a hurdle.
Good work....
David
David McNab wrote:
> Hi gnupic and picforth people,
>
> This is a pre-announcement of a coming Forth compiler for the
> PIC18Fxxx chips. I've tentatively called it 'PIC18forth', but am open
> to suggestions for a better name.
>
> PIC18forth is radically different from the PIC16Fxxx-only PicForth
> compiler. Almost nothing in common, since I've written PIC18forth from
> scratch.
>
> Quick summary of features - love them and loathe them:
>
> * signed/unsigned 16-bit data cells and operators
> * software return stack
> * data stack grows up (increasing addresses), while
> return stack grows down (decreasing addresses)
> * total allocated size of data+return stacks can
> be set to anything between 16 and 1024 bytes
> * compiler is written in Python, and is very approachable
> and extensible, even for people new to the code
> * integrated into gputils
> * forth sources get compiled to relocatable assembly (.asm)
> sources, ready for gpasm and gplink
> * the generated code embeds a 16-bit forth vm (token threaded
> execution model) which executes bytecodes
> * the generated code is self-contained, and once assembled
> and linked, can be downloaded/flashed as a standalone program
> * FSR0 is usually used for data stack ptr, FSR1 usually
> used as return stack ptr, FSR2 used as general purpose
> pointer
> * full support for locals (John Hopkins syntax, data
> gets transferred from data stack to a frame on return stack
> * vm design favours code density over execution speed
> * contents of 'code .. end-code' definitions are included
> verbatim in generated assembly source (with '\' comments
> changed to ';')
> * the defining-words 'primitive .. end-primitive' can be
> used in place of 'code .. end-code', to define a word
> in assembler which will be available as a single-byte
> vm instruction - easy to add/remove primitives at will
> * maps to von Neumann memory model, with addresses <8000H
> treated as RAM addresses, and addresses>=8000H treated
> as program ROM addresses
>
> If you're currently hacking with PIC18Fxxx chips, and are interested
> in trying out PIC18forth, please mail me and I'll put you on a list
> for pre-alpha-testers.
>
------------------------------
Message: 4
Date: Mon, 17 Jan 2005 11:41:47 +1300
From: David McNab <david at rebirthing.co.nz>
Subject: Re: [PicForth] pre-announcing Forth for PIC18F chips
To: "J.C. Wren" <jcwren at jcwren.com>
Cc: picforth at lists.rfc1149.net, gnupic at linuxhacker.org
Message-ID: <41EAEDAB.8010602 at rebirthing.co.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
J.C. Wren wrote:
> Are the von Neuman memory map limits fixed? The PIC18F8621, for
> example, has 3K of RAM, and 64K of FLASH. I'd like to be able to use
> all the RAM, and 61K of the FLASH.
Very good point indeed. Makes sense that a user of such a chip would
want to org the bytecodes to address 0xC00 or later, and feel safe that
'!', '@', 'c@', 'c!', '+!' etc will hit RAM for addresses < 0xC00, and
ROM for addresses >= 0xC00. I'll add this immediately.
(btw - '!', 'c!' etc act as 'placebos' for addresses in ROM space, ie
they consume the data and address args but do nothing. I've done this
because it would be nightmarishly inefficient to:
- read into RAM the 64-byte page within which the target address
resides
- write the data to the correct location within the cached page in
RAM
- erase the 64-byte page in ROM
- reprogram the page in ROM with the cached data.
Also, it would accelerate program memory 'wear'.
If one wants ROM storage operators, one can easily add the required
primitives.
> The '8621 also has a 31 entry hardware stack, with stack underflow
> and overflow detection.
Ditto across the 18F range, AFAIK. Makes me wonder why people still put
up with PIC16F chips, when pin-compatible 18F chips are only pennies
more expensive.
> If it's not too unreasonable, it might be nice
> to be able to use that instead of a software stack.
For calls to and between 'code' and 'primitive' words, I'm already using
the hardware return stack. I only use the software return stack for
calls between colon-defined words. In other words, with:
primitive fred ... <assembler statements> ... end-primitive
code mary ... <assembler statements> ... end-code
: jim ... fred ... mary ... ;
: alice ... jim ... fred ... mary ... ;
the software return stack is only used when 'alice' calls 'jim'.
I see problems in using the hardware return stack for calls between
colon-defined words:
1) The vm reads and 'executes' bytecodes. Users' high-level
(colon-defined) forth words get compiled down to strings of bytecode,
not native code.
FWICT, the 'PUSH' instruction cannot push arbitrary data, it can only
push PC+2, which means we'd need some serious acrobatics to push
bytecode return addresses (if it can be done at all).
2) I use the return stack for storage of JH locals.
I am hardwired in my choice to support locals. Sorry, purists! :P
For example:
: foo { arg1 arg2 | local1 }
...
{ local2 | local3 }
...
;
If the calling prog 'bar' executes:
$451a $3431 $1139 foo
then immediately after entry to foo, the stacks viewed byte-wise look like:
DATA: .. 1a 45 31 34 39 11
RETURN: 0 barReturnH barReturnL ...
Note that we're using little-endian. Also, the extra '0' on the return
stack is a 'frame size'. And also, we're showing the return stack
growing downward in memory.
After executing the first locals statement, the stacks look like:
DATA: .. 1a 45
RETURN: 6 0 0 31 34 39 11 barReturnH barReturnL ..
Where the '6' is the new frame size, the '0 0' is the initialised local
'local1', the '31 34' is 'arg1' ripped from data stack, and '39 11' is
arg2 ripped from the data stack.
Similarly, if before executing the second locals statement, the data
stack has become:
DATA: .. 1a 45 67 69
ie, statements in foo have pushed the extra value $6967 onto the stack,
then the second locals statement would change the stacks to:
DATA: .. 1a 45
RETURN: a 0 0 67 69 0 0 31 34 39 11 barReturnH barReturnL ..
So as you can see, each word call has a return stack cost of 3 bytes
plus total size of all locals temporarily created by that word.
If you can suggest a way to efficiently use the PIC18 hardware return
stack with all this, then please share your thoughts.
Cheers
David
> For large programs,
> it's obviously inadequate, but for a lot of projects it's more than
enough.
>
> --jc
>
> David McNab wrote:
>
>> Hi gnupic and picforth people,
>>
>> This is a pre-announcement of a coming Forth compiler for the
>> PIC18Fxxx chips. I've tentatively called it 'PIC18forth', but am open
>> to suggestions for a better name.
>>
>> PIC18forth is radically different from the PIC16Fxxx-only PicForth
>> compiler. Almost nothing in common, since I've written PIC18forth from
>> scratch.
>>
>> Quick summary of features - love them and loathe them:
>>
>> * signed/unsigned 16-bit data cells and operators
>> * software return stack
>> * data stack grows up (increasing addresses), while
>> return stack grows down (decreasing addresses)
>> * total allocated size of data+return stacks can
>> be set to anything between 16 and 1024 bytes
>> * compiler is written in Python, and is very approachable
>> and extensible, even for people new to the code
>> * integrated into gputils
>> * forth sources get compiled to relocatable assembly (.asm)
>> sources, ready for gpasm and gplink
>> * the generated code embeds a 16-bit forth vm (token threaded
>> execution model) which executes bytecodes
>> * the generated code is self-contained, and once assembled
>> and linked, can be downloaded/flashed as a standalone program
>> * FSR0 is usually used for data stack ptr, FSR1 usually
>> used as return stack ptr, FSR2 used as general purpose
>> pointer
>> * full support for locals (John Hopkins syntax, data
>> gets transferred from data stack to a frame on return stack
>> * vm design favours code density over execution speed
>> * contents of 'code .. end-code' definitions are included
>> verbatim in generated assembly source (with '\' comments
>> changed to ';')
>> * the defining-words 'primitive .. end-primitive' can be
>> used in place of 'code .. end-code', to define a word
>> in assembler which will be available as a single-byte
>> vm instruction - easy to add/remove primitives at will
>> * maps to von Neumann memory model, with addresses <8000H
>> treated as RAM addresses, and addresses>=8000H treated
>> as program ROM addresses
>>
>> If you're currently hacking with PIC18Fxxx chips, and are interested
>> in trying out PIC18forth, please mail me and I'll put you on a list
>> for pre-alpha-testers.
>>
>
>
>
------------------------------
Message: 5
Date: Sun, 16 Jan 2005 18:00:33 -0500
From: "Mark J. Dulcey" <mark at buttery.org>
Subject: Re: [PicForth] pre-announcing Forth for PIC18F chips
To: David McNab <david at rebirthing.co.nz>
Cc: gnupic at linuxhacker.org, picforth at lists.rfc1149.net
Message-ID: <41EAF211.1020306 at buttery.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
> Ditto across the 18F range, AFAIK. Makes me wonder why people still put
> up with PIC16F chips, when pin-compatible 18F chips are only pennies
> more expensive.
First, some applications (especially consumer electronics) actually are
sensitive to those pennies. If you're going to make a million units of
something, it may be worth some extra development time to shave 10 cents
off the unit cost of each one.
Second, if you are using a mixture of large (28 pin and larger) and
small (18 pin and smaller) PICs in an application, being able to use the
same code base in all of them might have advantages. Now that the
18F1220 and 18F1320 are available, the 18F has moved down into the
18-pin world (though there the cost difference is over $1 per chip --
compare the prices of the 18F1220 and the 16F628A), but there is still
no 18F series chip in any smaller package.
Finally, the disadvantages of the 16F instruction set aren't as serious
for small programs, where you don't have to deal with the horrible
paging stuff.
------------------------------
_______________________________________________
PicForth mailing list
PicForth at lists.rfc1149.net
http://lists.rfc1149.net/mailman/listinfo/picforth
End of PicForth Digest, Vol 10, Issue 1
***************************************
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 1/12/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 1/17/2005
More information about the PicForth
mailing list