charleses at cvs.com.au
charleses at cvs.com.au
Tue Aug 30 20:59:10 EDT 2005
The portability solution is to stick to ANSI FORTH.
ucFORTH can be created under GFORTH on the PC and ucFORTH on coldfire so I well understand the issue.
GFORTH and ucFORTH use the same class object system, I quite like the GFORTH solution, never did like the FORTH inc solution.
Local variables are different, I don't like the standard and I don't like the GFORTH solution, so I have stuck with ours. We use a local dictionary that allows you to define variables, values and constant with local scope.
I am however fed up with not being able to use local variables in code to be compiled under both systems as a result I plan on extending ucFORTH to support the GFORTH solution as well.
The main portability problems are created by standard committee attempts to move languages from hardware. In C the problem is solved by creating new types. U16 U32 etc.
In forth don't use C@ C! for byte operations, they are character operators ( think unicode). Define the words set b! and b at .
If you plan on support the code on big and little endian ( as I do ) have a set of big endian and little endian operators.
At the start of the cross compiler you will find code that works out if it is running on a big endian or little endian machine.
1) uCFORTH comes with a good coldfire assembler. If you do a GFORTH port you will have to write the assembler or take ours. Ours will compile under GFORTH so that is a easy option.
2) The floating point code is written for speed not ANSI standard. Because the exponent is 32 bit, simultaneous equation solving with orders less than 6 ( I've never had to go higher) can be done using multiplication and with no array conditioning if you start with numbers that can be described by ANSI standard floats. Most of the FLOAT package is written in ANSI FORTH. If you take the assembler you will be able to take the floating point package. It is pretty complete supporting trig functions etc.
3) The I/O subsystem is object based.
4) The number I/O system supports using modification characters as well as the base changing words ( and is extendible)
Once again stick to the ANSI standard if code is to be compiled on both.
5) It's subroutine threaded, GFORTH is only directed threaded.
\ On the MMU issue.
ucLinux supports shared library, 99% of uCFORTH is implemented as a re-entrant shared library. If you get involved in cross compiling you can add to the shared library. The application code resides in it's own memory space. Simple way is to create a script that calls the ucf interpreter ( see the file FORTH). ucLinux will then invoke the small task specific portion which will extend it's dictionary using the script, the script will execute the word you want executed if you put it at the end.
You can create a binary image if you want to, but I don't bother.
It was this issue that tipped me to porting coldforth to uclinux instead of getting GFORTH going.
----- Original Message -----
From: Andrew Holt
Sent: 8/31/2005 8:33:41 AM
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] gforth
> I have no problem, as such. To be honest I have not given uCforth a
> proper workout. Though one of the nice things about gforth is that I
> can scale the hardware up if required.
> On 30 Aug 2005, at 22:37, "" <charleses at cvs.com.au>
> <charleses at cvs.com.au> wrote:
> > What was your problem with uCFORTH.
> > It doesn't have a multitasker because the libary is shared and it
> > is better to run multiple tasks under unLinux.
> I may be in error here, but since I have no mmu I can't share pages
> as I would on a VM Linux, does this solution not use more memory,
> plus how do my forth instance communicate ?
> > Regards
> > Charles
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> This message was resent by uclinux-dev at uclinux.org
More information about the uClinux-dev