Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #46786 > unrolled thread

How to write a compile documentation

Back to article view | Back to comp.lang.forth

Contents

  How to write a compile documentation Cecil - k5nwa <cecil.bayona@k5nwa.com> - 2016-04-26 08:40 -0700
    Re: How to write a compile documentation foxaudioresearch@gmail.com - 2016-04-27 11:47 -0700
      Re: How to write a compile documentation Cecil - k5nwa <cecil.bayona@k5nwa.com> - 2016-04-27 14:02 -0700
        Re: How to write a compile documentation Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:05 -0700
        Re: How to write a compile documentation Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-04-28 12:12 +0000
          Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-04-28 06:54 -0700
          Re: How to write a compile documentation Cecil - k5nwa <cecil.bayona@k5nwa.com> - 2016-04-28 20:10 -0700
          Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-10 12:20 -0500
            Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-10 20:51 -0500
              Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-10 20:32 -0700
              Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-10 20:32 -0700
                Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-11 00:11 -0500
                  Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-10 22:39 -0700
                Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 12:23 -0500
                  Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-12 12:50 -0700
                    Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 16:19 -0500
                      Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-13 06:36 -0700
                        Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-13 09:44 -0500
                          Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-13 08:01 -0700
                            Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-13 13:00 -0500
                              Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-13 12:51 -0700
                                Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-13 17:15 -0500
                                  Re: How to write a compile documentation Mikael Nordman <oh2aun@gmail.com> - 2016-05-13 21:31 -0700
                                    Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-14 10:19 -0500
                        Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-21 19:29 -0500
      Re: How to write a compile documentation "HAA" <someone@microsoft.com> - 2016-04-28 12:34 +1000
        Re: How to write a compile documentation foxaudioresearch@gmail.com - 2016-04-28 06:14 -0700
    Re: How to write a compile documentation Cecil - k5nwa <cecil.bayona@k5nwa.com> - 2016-05-02 13:36 -0700
      Re: How to write a compile documentation Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-02 22:25 +0100
        Re: How to write a compile documentation Cecil - k5nwa <cecil.bayona@k5nwa.com> - 2016-05-02 16:00 -0700
          Re: How to write a compile documentation Paul Rubin <no.email@nospam.invalid> - 2016-05-02 17:48 -0700
            Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-02 21:16 -0500
              Re: How to write a compile documentation Cecil Bayona <cbayona@cbayona.com> - 2016-05-02 21:24 -0500

Page 1 of 2  [1] 2  Next page →

#46786 — How to write a compile documentation

I been thinking for a while to create a PIC24/DSPIC cross compiler that resides in a Windows 10 computer and tethered to a PIC development board.
The problem I see is that I have not found decent documentation on how to create such a beast, I have read Brad Rodriguez articles but they leave out a lot of detail. I also have several books on FORTH but they are mainly dealing on how to use FORTH.

I wrote a compiler  over 40 years ago so the source is gone and the details are hazy , beside I did not write it in FORTH but used a Macro Processing language called Stage2 which almost no one has hear of it. I currently own SwiftForth, MPE Professional for ARM, and iForth but have not updated it in years.

Is there any literature available that gives some insight into the design of a cross compiler? I would appreciate any information.

Thanks

Cecil

[toc] | [next] | [standalone]

#46812

On Tuesday, April 26, 2016 at 11:40:06 AM UTC-4, Cecil - k5nwa wrote:
> I been thinking for a while to create a PIC24/DSPIC cross compiler that resides in a Windows 10 computer and tethered to a PIC development board.
> The problem I see is that I have not found decent documentation on how to create such a beast, I have read Brad Rodriguez articles but they leave out a lot of detail. I also have several books on FORTH but they are mainly dealing on how to use FORTH.
> 
> I wrote a compiler  over 40 years ago so the source is gone and the details are hazy , beside I did not write it in FORTH but used a Macro Processing language called Stage2 which almost no one has hear of it. I currently own SwiftForth, MPE Professional for ARM, and iForth but have not updated it in years.
> 
> Is there any literature available that gives some insight into the design of a cross compiler? I would appreciate any information.
> 
> Thanks
> 
> Cecil

Hi Cecil,

Having spent a lot of hobby time (off and on, mostly off) building a cross-compiler that does nothing more than create a DOS FORTH.COM file, I sympathize.
However the FORTH.COM can include other files as it has a set of ANS/ISO file words for DOS that I wrote.

Forth Programmers Handbook, Conklin and Rather, has a chapter that explains how to create a framework that is used by the commercial cross-compilers but not too many down and dirty details.  

I would happily share my work with you but I must tell you the memory model is for a segmented DOS system called HsForth.  If you could re-write the target memory part and the change the assembler primitives for whatever Forth a lot much of the hi-level work comes from other public domain Forth systems. Camel Forth and FPC are the biggest contributors.  I cannot share the HsForth kernel as I do not have permission to do that, but I have modified it to be mostly ANS style Forth so it is possible to move it. There are a few non-standard words for saving the file at the end of the process, but they can be re-created by you.

You can contact me at this email if you are interested.

BF

[toc] | [prev] | [next] | [standalone]

#46815

I have a copy of the FORTH Inc/ MPE cross compiler guide and the Forth Programmers Guide but both are weak on details. So far the Brad Rodriguez guide on building a FORTH assembler is fairly clear, and with examples so I like that paper. I used it in the past to create an AVR assembler that worked OK.

One of my favorite FORTH compiler is Pygmy FORTH, it's source is available but it suffers from also being a DOS only FORTH, which is a problem as I am not familiar with the i86 instruction set nor interfacing to DOS, which I rather not become familiar with unless there is no other choice, it does have a metacompiler that is easy to implement. I suppose that using a modern compiler to create a working version of it that is all FORTH would not be bad but it's a long way to get to resolve what I want.

So I might try looking at some of the "C" kernels that are still available, another option is using "Timbre" which has built in some very powerful text processing capabilities, I've played with it a little bit to generate a limited FORTH to PIC assembler conversion with some optimizations, but the documentation is sparse at best.

Part of the problem I see is that many FORTH sites are gone, and the few that are around have multitudes of broken links so it's difficult to get information on the subject, not that there was a whole lot to begin with.

[toc] | [prev] | [next] | [standalone]

#46818

Cecil - k5nwa <cecil.bayona@k5nwa.com> writes:
> So I might try looking at some of the "C" kernels that are still
> available,

If you want something ridiculously simple that bootstraps from C,
there's an eforth or eforth-inspired one:

http://chiselapp.com/user/tehologist/repository/compc/home

It's very bare bones but could be extended as much as you felt like doing.

[toc] | [prev] | [next] | [standalone]

#46827

On 2016-04-27, Cecil - k5nwa <cecil.bayona@k5nwa.com> wrote:

Please restirct lines to 72 char's
> I have a copy of the FORTH Inc/ MPE cross compiler guide and the
    Forth Programmers Guide but both are weak on details. So far the Brad
    Rodriguez guide on building a FORTH assembler is fairly clear, and
    with examples so I like that paper. I used it in the past to create
    an AVR assembler that worked OK.

 >
> One of my favorite FORTH compiler is Pygmy FORTH, it's source is
    available but it suffers from also being a DOS only FORTH, which is a
    problem as I am not familiar with the i86 instruction set nor
    interfacing to DOS, which I rather not become familiar with unless
    there is no other choice, it does have a metacompiler that is easy to
    implement. I suppose that using a modern compiler to create a working
    version of it that is all FORTH would not be bad but it's a long way
    to get to resolve what I want.
>
> So I might try looking at some of the "C" kernels that are still
    available, another option is using "Timbre" which has built in some
    very powerful text processing capabilities, I've played with it a
    little bit to generate a limited FORTH to PIC assembler conversion
    with some optimizations, but the documentation is sparse at best.

As far as text processing in behalf of Forth compilation is concerned,
my 6 word mini-string package fills in all my needs. Very powerful
text processing capabilities probably shouldn't be high on your shopping
list.

> Part of the problem I see is that many FORTH sites are gone, and the
    few that are around have multitudes of broken links so it's difficult
    to get information on the subject, not that there was a whole lot to
    begin with.

1. PIC is a poor source to implement Forth for. The small processors
of the PIC are horrendous. The large processors are incompatible with
them.
2. You must decide whether you are willing to invest in assembly language
expertise for PIC24, (with little spin off) or suffer the overhead of
a Forth in C compiler. The advantage of Forth-in-C is portability,
you sacrifice that by limiting to PIC24. The advantage of Forth is
interactivity, you sacrifice that by writing a cross compiler.

It makes sense to cut out the middle man and write your application in C.

I share your fascination with compilers (I evolved ciforth), but compilers
are such a small part of the deal. Before your cross compiler is useful,
you have to write libraries or find a way to tap in existing libraries.

Groetjes Albert

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#46829

On Thursday, April 28, 2016 at 3:12:24 PM UTC+3, Albert van der Horst wrote:
> 1. PIC is a poor source to implement Forth for. The small processors
> of the PIC are horrendous. The large processors are incompatible with
> them.

The PIC24/30/33 has actually the best 16-bit CPU architecture for implementing Forth.
Better addressing modes than the MSP430 for example.

> 2. You must decide whether you are willing to invest in assembly language
> expertise for PIC24, (with little spin off) or suffer the overhead of
> a Forth in C compiler. The advantage of Forth-in-C is portability,
> you sacrifice that by limiting to PIC24. The advantage of Forth is
> interactivity, you sacrifice that by writing a cross compiler.

As inspiration you could try the native PIC24/30/33 FlashForth.
It is a subroutine threaded inlining Forth written completely in assembly.
It can link to the existing Microchip libraries. It was done as an example to support floating point routines.
A cross-compiler would be interesting. I seem to remember that Forth Inc or MPE has one. 

BR Mikael
http://www.flashforth.com

[toc] | [prev] | [next] | [standalone]

#46833

Currently I have a Pascal compiler for the dsPIC family I prefer that to C, C can be nerve racking when you have Memory leak issues, that is why I would prefer an interactive FORTH compiler.

Cross compile to a tethered system, the PC compiles and optimizes the code, but the the Window system would be interactive with the target, like many of the other commercial systems such as SwiftX or MPE VFX compilers. I'm not interested in the smaller CPUs of that family, most projects I want it for would use the dsPIC family of chips.

Cecil

[toc] | [prev] | [next] | [standalone]

#47015

> 1. PIC is a poor source to implement Forth for. The small processors
> of the PIC are horrendous. The large processors are incompatible with
> them.
> 2. You must decide whether you are willing to invest in assembly language
> expertise for PIC24, (with little spin off) or suffer the overhead of
> a Forth in C compiler. The advantage of Forth-in-C is portability,
> you sacrifice that by limiting to PIC24. The advantage of Forth is
> interactivity, you sacrifice that by writing a cross compiler.
>
> It makes sense to cut out the middle man and write your application in C.
>
> I share your fascination with compilers (I evolved ciforth), but compilers
> are such a small part of the deal. Before your cross compiler is useful,
> you have to write libraries or find a way to tap in existing libraries.
>
> Groetjes Albert
>
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
>

I been thinking of an alternative route, just to get something going, 
once I get going it's hard to stop unless something is resolved. To get 
going do an intermediate project as follows;

1. I'm thinking of getting a $13 MSP-EXP430FR5969 Experimenter Board and 
install noForth as a vehicle  to get me familiar again with Forth in an 
embedded environment.
2. Use noForth as my basis to create a PIC24/dsPic Forth.
3. Then when it is working OK, start adapting to have a cross compiler 
to a tethered system.

The advantage is that there are several steps each getting harder but 
with success behind you it's easier to keep going, I am not as 
experience as many here in creating a Forth compiler. I created one a 
long time ago using Stage2 a very powerful text processing language but 
the Forth compiler although fully functional did not have the structure 
of a real Forth compiler, it just behaved as one and generated optimized 
assembler code for several CPU chips.

The disadvantage is that I tend to over specify things, as an example 
for a simple needed project I want to make an oven controller to be used 
in soldering SMD boards, not too difficult, implement a PID loop to 
follow a temperature profile while controlling the oven heater, cooling 
fans, and report the status to either a display or to a PC. Another 
disadvantage is I keep hearing that TI might be turning down support for 
the MSP430 family

A MSP430 board contains more that plenty processing power and IO pins 
but it keeps bugging me that for $11 I can also buy a SMT Nucleo board 
with an ARM F4 CPU and 512K of Flash and 128KB of RAM. Yet the Nucleo 
board is such a massive  overkill, actually a small 8 bit PIC, or AVR 
chip can do the job well but I keep resisting buying the $13 
MSP-EXP430FR5969 Experimenter Board.

In this case I can use the MSP430 board to do my project, get familiar 
again with Forth in an embedded situation, and more importantly be a 
vehicle to make some progress on creating  a PIC24/dsPIC project which 
the Nucleo board will not be as helpful with but I believe there is also 
a version for noForth for ARM targets.

There are other approaches also, using a Arduino board with an AVR Forth 
is also viable, as I have JTAG tools to various CPUs, I also have an old 
Olimex Serial port to MSP430 JTAG adapter also which I'm not sure it 
would work there days with Windows 10.

Any advise would be welcomed, at this point there are too many choices.
-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47017

On 5/10/2016 12:20 PM, Cecil Bayona wrote:
>
>> 1. PIC is a poor source to implement Forth for. The small processors
>> of the PIC are horrendous. The large processors are incompatible with
>> them.
>> 2. You must decide whether you are willing to invest in assembly language
>> expertise for PIC24, (with little spin off) or suffer the overhead of
>> a Forth in C compiler. The advantage of Forth-in-C is portability,
>> you sacrifice that by limiting to PIC24. The advantage of Forth is
>> interactivity, you sacrifice that by writing a cross compiler.
>>
>> It makes sense to cut out the middle man and write your application in C.
>>
>> I share your fascination with compilers (I evolved ciforth), but
>> compilers
>> are such a small part of the deal. Before your cross compiler is useful,
>> you have to write libraries or find a way to tap in existing libraries.
>>
>> Groetjes Albert
>>
>> --
>> Albert van der Horst, UTRECHT,THE NETHERLANDS
>> Economic growth -- being exponential -- ultimately falters.
>> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
>>
>
> I been thinking of an alternative route, just to get something going,
> once I get going it's hard to stop unless something is resolved. To get
> going do an intermediate project as follows;
>
> 1. I'm thinking of getting a $13 MSP-EXP430FR5969 Experimenter Board and
> install noForth as a vehicle  to get me familiar again with Forth in an
> embedded environment.
> 2. Use noForth as my basis to create a PIC24/dsPic Forth.
> 3. Then when it is working OK, start adapting to have a cross compiler
> to a tethered system.
>
> The advantage is that there are several steps each getting harder but
> with success behind you it's easier to keep going, I am not as
> experience as many here in creating a Forth compiler. I created one a
> long time ago using Stage2 a very powerful text processing language but
> the Forth compiler although fully functional did not have the structure
> of a real Forth compiler, it just behaved as one and generated optimized
> assembler code for several CPU chips.
>
> The disadvantage is that I tend to over specify things, as an example
> for a simple needed project I want to make an oven controller to be used
> in soldering SMD boards, not too difficult, implement a PID loop to
> follow a temperature profile while controlling the oven heater, cooling
> fans, and report the status to either a display or to a PC. Another
> disadvantage is I keep hearing that TI might be turning down support for
> the MSP430 family
>
> A MSP430 board contains more that plenty processing power and IO pins
> but it keeps bugging me that for $11 I can also buy a SMT Nucleo board
> with an ARM F4 CPU and 512K of Flash and 128KB of RAM. Yet the Nucleo
> board is such a massive  overkill, actually a small 8 bit PIC, or AVR
> chip can do the job well but I keep resisting buying the $13
> MSP-EXP430FR5969 Experimenter Board.
>
> In this case I can use the MSP430 board to do my project, get familiar
> again with Forth in an embedded situation, and more importantly be a
> vehicle to make some progress on creating  a PIC24/dsPIC project which
> the Nucleo board will not be as helpful with but I believe there is also
> a version for noForth for ARM targets.
>
> There are other approaches also, using a Arduino board with an AVR Forth
> is also viable, as I have JTAG tools to various CPUs, I also have an old
> Olimex Serial port to MSP430 JTAG adapter also which I'm not sure it
> would work there days with Windows 10.
>
> Any advise would be welcomed, at this point there are too many choices.

I made an error, it's Mecrisp Forth not noForth that has a MSP430 and a 
ARM version of their compilers

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47018

Cecil,
You could start with FlashForth.
It works directly on pic24 and dsPic.
It has been developed for 5 years and supports almost all pic24 and dsPic variants.

I think mecrisp is written for vonNeumann architecture. FlashForth is written for Harvard architecture like the PICs.

OH2AUN / Mikael

[toc] | [prev] | [next] | [standalone]

#47019

Cecil,
You could start with FlashForth.
It works directly on pic24 and dsPic.
It has been developed for 5 years and supports almost all pic24 and dsPic variants.

I think mecrisp is written for vonNeumann architecture. FlashForth is written for Harvard architecture like the PICs.

OH2AUN / Mikael

[toc] | [prev] | [next] | [standalone]

#47020

On 5/10/2016 10:32 PM, Mikael Nordman wrote:
> Cecil,
> You could start with FlashForth.
> It works directly on pic24 and dsPic.
> It has been developed for 5 years and supports almost all pic24 and dsPic variants.
>
> I think mecrisp is written for vonNeumann architecture. FlashForth is written for Harvard architecture like the PICs.
>
> OH2AUN / Mikael
>
Thanks, mecrisp was mentioned as a a correction to something I said, I 
was not planning on using it as it's all assembler which would be a lot 
more work, I was thinking of using noForth which has a small core of 
assembler and the rest in Forth itself.

Also the dsPIC chips although it has a Harvard architecture, it has 
mapping registers that make the RAM and other memory spaces show up in 
the code space so it emulates a vonNeumann architecture so that is not a 
major issue.

FlashForth looks fine for using it as is but has a good portion of Forth 
in assembler with extensive use of macros so there would be a lot of 
conversion there to change it to a Forth assembler or in creating a 
Forth assembler that has macro capability and uses infix notation, 
either way it's a lot of work, everything so far is complicated.

I almost bought the MSP430 boards, I actually saved the order in Mouser, 
but currently I'm not sure how to approach this problem. I own a copy of 
MPE Professional ARM cross compiling software with source so I will 
discuss it with Stephen Pelc on the phone to get a clue how difficult it 
will be to modify that software to generate PIC code.

In reality I'm beginning to question if this project should be done at 
all, instead maybe I should just use FlashForth on occasion with dsPICs 
but use ARM hardware and MPE ARM Forth for most projects, the ARM boards 
are so cheap now, and so capable, yes they are overkill in most of my 
projects, but I already have the tools, and the boards are inexpensive.

Any new projects it's just as easy to layout a board with an ARM CPU as 
it is with a dsPIC.

I have quite a few tools for ARM, MPE Professional Cross Development 
Software, MikroE Pascal compiler, and Rowley C compiler, along with 
Seeger, and several other JTAG devices so if I use ARM devices I am well 
covered, and ready to create projects.

On my order that I saved I also have several Nucleo F446E boards for a 
cost of $10.33 each, they are Arduino size boards with a F4 CPU that can 
run at 180MHz, 512K of Flash, 128K of RAM, and tons of IO including I2S 
which is required for some projects, also Arduino compatible connectors 
for using cheap accessories, so maybe I should just use ARM boards and 
not be concerned about overkill.

The more I think about it the more I think that the best path is to use 
ARM for new projects. The dsPIC has one advantage, quite a few devices 
are available in PDIP form which is easy to use when making a one of a 
kind prototype. but then I can use FlashForth, and I also have MikroE 
Pascal compiler for those devices.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47021

On Wednesday, May 11, 2016 at 8:11:24 AM UTC+3, Cecil - k5nwa wrote:

> 
> Also the dsPIC chips although it has a Harvard architecture, it has 
> mapping registers that make the RAM and other memory spaces show up in 
> the code space so it emulates a vonNeumann architecture so that is not a 
> major issue.
> 
Actually it is the other way around. The dsPIC mapping makes flash show up in data space so that the MAC can read constants from flash.

BR Mikael

[toc] | [prev] | [next] | [standalone]

#47046

On 5/10/2016 10:32 PM, Mikael Nordman wrote:
> Cecil,
> You could start with FlashForth.
> It works directly on pic24 and dsPic.
> It has been developed for 5 years and supports almost all pic24 and dsPic variants.
>
> I think mecrisp is written for vonNeumann architecture. FlashForth is written for Harvard architecture like the PICs.
>
> OH2AUN / Mikael
>
I had a question for you on FlashForth.

On the dsPIC version how much FLASH can the compiler handle?

I ask as I'm getting ready to put in an order on Mouser and I didn't 
want to order chips that will not work or use all the FLASH.

I was looking at the following SPDIP chips;

DSPIC33EP128GP502-I/SP with 128K of FLASH and 16KB of RAM

DSPIC33EP128MC202-I/SP with 128K of FLASH and 16KB of RAM This one is 
the #1 choice for most projects due to cost and capability.

DSPIC33EP512MC202-I/SP with 512K of FLASH and 48KB of RAM

Thanks
-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47055

On Thursday, May 12, 2016 at 8:23:38 PM UTC+3, Cecil - k5nwa wrote:

> I had a question for you on FlashForth.
> 
> On the dsPIC version how much FLASH can the compiler handle?
> 
FF maps the I/O, ram and flash into a 16 bit address space.
On the EP series the address space is divided like this:
I/O , 4 Kbytes
RAM , 16 KBytes
FLASH , the rest 64-16-4 = 44 Kbytes (uses 66 Kbytes of the flash).

Outside the 16-bit address space 12 KB of flash is used by the EP series for
EEPROM emulation for TURNKEY, DP, IDP and LATEST

On the the FJ series the address space is divided like this:
I/O , 2 Kbytes
RAM , 16 KBytes
FLASH , the rest 64-16-2 = 46 Kbytes (uses 69 Kbytes of the flash)

FJ series uses 6 KBytes of flash for the EEPROM emulation.

With X@ and X!n you can store and fetch data in the whole 
24 bit Flash address space.

If you wonder why 44 KBytes of addressable data flash uses
66 Kbytes of flash memory, that is because as program flash there
is an extra byte of flash used for one word address.
So when microchip sells a 128 Kbytes device,
only 2/3 of the flash is available in the data address space.
This is good to know, but FlashForth handles this so you don't
need to care that much.

The EP series can run on 70 MIPS, but to achieve that it uses a small pipeline.
The FJ series (40 MIPS) does not use a pipeline.
So the EP line is better for running MAC operations without any branches,
while the FJ series is better for a subroutine threaded forth, because the
call/ret pair is twice as fast.

OTOH, FlashForth inlines quite a lot of code so the effect if the pipeline
is not that big.

Then of course your choice of chip depends on the peripherals you want...


> I ask as I'm getting ready to put in an order on Mouser and I didn't 
> want to order chips that will not work or use all the FLASH.
> 
> I was looking at the following SPDIP chips;
> 
> DSPIC33EP128GP502-I/SP with 128K of FLASH and 16KB of RAM
Works, I have used the 256 Kbyte variant.

> 
> DSPIC33EP128MC202-I/SP with 128K of FLASH and 16KB of RAM This one is 
> the #1 choice for most projects due to cost and capability.
Works just as well.

> 
> DSPIC33EP512MC202-I/SP with 512K of FLASH and 48KB of RAM
Should work also.
There may be only 12 Kbytes FLASH available for the compiler,
but you can configure the border between addressable RAM and FLASH
to anything you want. 

BR Mikael

[toc] | [prev] | [next] | [standalone]

#47056

On 5/12/2016 2:50 PM, Mikael Nordman wrote:
> On Thursday, May 12, 2016 at 8:23:38 PM UTC+3, Cecil - k5nwa wrote:
>
>> I had a question for you on FlashForth.
>>
>> On the dsPIC version how much FLASH can the compiler handle?
>>
> FF maps the I/O, ram and flash into a 16 bit address space.
> On the EP series the address space is divided like this:
> I/O , 4 Kbytes
> RAM , 16 KBytes
> FLASH , the rest 64-16-4 = 44 Kbytes (uses 66 Kbytes of the flash).
>
> Outside the 16-bit address space 12 KB of flash is used by the EP series for
> EEPROM emulation for TURNKEY, DP, IDP and LATEST
>
> On the the FJ series the address space is divided like this:
> I/O , 2 Kbytes
> RAM , 16 KBytes
> FLASH , the rest 64-16-2 = 46 Kbytes (uses 69 Kbytes of the flash)
>
> FJ series uses 6 KBytes of flash for the EEPROM emulation.
>
> With X@ and X!n you can store and fetch data in the whole
> 24 bit Flash address space.
>
> If you wonder why 44 KBytes of addressable data flash uses
> 66 Kbytes of flash memory, that is because as program flash there
> is an extra byte of flash used for one word address.
> So when microchip sells a 128 Kbytes device,
> only 2/3 of the flash is available in the data address space.
> This is good to know, but FlashForth handles this so you don't
> need to care that much.
>
> The EP series can run on 70 MIPS, but to achieve that it uses a small pipeline.
> The FJ series (40 MIPS) does not use a pipeline.
> So the EP line is better for running MAC operations without any branches,
> while the FJ series is better for a subroutine threaded forth, because the
> call/ret pair is twice as fast.
>
> OTOH, FlashForth inlines quite a lot of code so the effect if the pipeline
> is not that big.
>
> Then of course your choice of chip depends on the peripherals you want...
>
>
>> I ask as I'm getting ready to put in an order on Mouser and I didn't
>> want to order chips that will not work or use all the FLASH.
>>
>> I was looking at the following SPDIP chips;
>>
>> DSPIC33EP128GP502-I/SP with 128K of FLASH and 16KB of RAM
> Works, I have used the 256 Kbyte variant.
>
>>
>> DSPIC33EP128MC202-I/SP with 128K of FLASH and 16KB of RAM This one is
>> the #1 choice for most projects due to cost and capability.
> Works just as well.
>
>>
>> DSPIC33EP512MC202-I/SP with 512K of FLASH and 48KB of RAM
> Should work also.
> There may be only 12 Kbytes FLASH available for the compiler,
> but you can configure the border between addressable RAM and FLASH
> to anything you want.
>
> BR Mikael
>
Up to this point I was not aware of all these limits partly due to using 
a Pascal Compiler which took care of all these items for me so I was 
ignorant of them, and likely they are not mapping the various memory 
spaces together so these limits are likely not there at all.

In any case, with FF then some of the extra space could be used to 
implement a disk of sorts but not to store active code? It turns out 
that the DSPIC33EP128MC202-I/SP is the cheapest part, parts with the 
64KB and lower FLASH are actually more expensive so there is no point in 
getting them. The only other chips I would use are the FJ parts they 
cost more but have I2S which occasionally is needed but for most things 
the MC parts have more than enough I/O, I2C and SPI I use quite often to 
hook up to Arduino peripherals.

Difficult decisions ahead, the MSP430 family are nice and clean from a 
programming point but they have limited speed and may be obsolete in the 
future, The dsPICs are way faster but although they have a nice 
instruction set are complex to use due to Harvard Architecture 
complexities, the AVR devices, are cheap but suffer from low processing 
power but there are plenty enough for many uses, the Arduino platform is 
cheap and very expandable.

Then there is ARM for high end applications that need high processing 
power or low cost. ST has a Nucleo F4 CPU that runs at 180MHz with 512K 
of Flash, 128K of RAM and tons of I/O for $10.33, that is a ridiculous 
amount of performance for little money.

I keep resisting using the ARM for small projects but I am hoping that 
FF would be useful enough for me to use it as a consistent platform for 
the PIC18F, dsPICs, and Arduino boards I have and want to use up.

A thought, how much of the resources are available to the programmer on 
the AVR versions for FF, I have a ton of Arduinos with the ATMEGA328P 
parts, and have a few of the 2560 versions also? I did not find that 
information although it might be in the source files.

Thanks

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47082

On Friday, May 13, 2016 at 12:19:22 AM UTC+3, Cecil - k5nwa wrote:
> On 5/12/2016 2:50 PM, Mikael Nordman wrote:
> > On Thursday, May 12, 2016 at 8:23:38 PM UTC+3, Cecil - k5nwa wrote:
> >
> >> I had a question for you on FlashForth.
> >>
> >> On the dsPIC version how much FLASH can the compiler handle?
> >>
> > FF maps the I/O, ram and flash into a 16 bit address space.
> > On the EP series the address space is divided like this:
> > I/O , 4 Kbytes
> > RAM , 16 KBytes
> > FLASH , the rest 64-16-4 = 44 Kbytes (uses 66 Kbytes of the flash).
> >
> > Outside the 16-bit address space 12 KB of flash is used by the EP series for
> > EEPROM emulation for TURNKEY, DP, IDP and LATEST
> >
> > On the the FJ series the address space is divided like this:
> > I/O , 2 Kbytes
> > RAM , 16 KBytes
> > FLASH , the rest 64-16-2 = 46 Kbytes (uses 69 Kbytes of the flash)
> >
> > FJ series uses 6 KBytes of flash for the EEPROM emulation.
> >
> > With X@ and X!n you can store and fetch data in the whole
> > 24 bit Flash address space.
> >
> > If you wonder why 44 KBytes of addressable data flash uses
> > 66 Kbytes of flash memory, that is because as program flash there
> > is an extra byte of flash used for one word address.
> > So when microchip sells a 128 Kbytes device,
> > only 2/3 of the flash is available in the data address space.
> > This is good to know, but FlashForth handles this so you don't
> > need to care that much.
> >
> > The EP series can run on 70 MIPS, but to achieve that it uses a small pipeline.
> > The FJ series (40 MIPS) does not use a pipeline.
> > So the EP line is better for running MAC operations without any branches,
> > while the FJ series is better for a subroutine threaded forth, because the
> > call/ret pair is twice as fast.
> >
> > OTOH, FlashForth inlines quite a lot of code so the effect if the pipeline
> > is not that big.
> >
> > Then of course your choice of chip depends on the peripherals you want...
> >
> >
> >> I ask as I'm getting ready to put in an order on Mouser and I didn't
> >> want to order chips that will not work or use all the FLASH.
> >>
> >> I was looking at the following SPDIP chips;
> >>
> >> DSPIC33EP128GP502-I/SP with 128K of FLASH and 16KB of RAM
> > Works, I have used the 256 Kbyte variant.
> >
> >>
> >> DSPIC33EP128MC202-I/SP with 128K of FLASH and 16KB of RAM This one is
> >> the #1 choice for most projects due to cost and capability.
> > Works just as well.
> >
> >>
> >> DSPIC33EP512MC202-I/SP with 512K of FLASH and 48KB of RAM
> > Should work also.
> > There may be only 12 Kbytes FLASH available for the compiler,
> > but you can configure the border between addressable RAM and FLASH
> > to anything you want.
> >
> > BR Mikael
> >
> Up to this point I was not aware of all these limits partly due to using 
> a Pascal Compiler which took care of all these items for me so I was 
> ignorant of them, and likely they are not mapping the various memory 
> spaces together so these limits are likely not there at all.

A 32-bit FF could access all flash. 
A 16-bit FF where flash addresses would be two cells long could be another approach.
But one point with FF was to keep things simple and concise for the user and as similar as possible  over the different architectures.
Therefore I have stayed with the 16-bit data and code space, and the mapping of the memory spaces.

OTOH you can fit a lot of code into the available flash space. 
My applications have never been so large, that I would have run out of code space.
 

> 
> In any case, with FF then some of the extra space could be used to 
> implement a disk of sorts but not to store active code?
 
The extra space can also be used for library code by tuning
the linker scripts. That was done for the floating point 
implementation, it calls the Microchip C-compiler library code.

>It turns out 
> that the DSPIC33EP128MC202-I/SP is the cheapest part, parts with the 
> 64KB and lower FLASH are actually more expensive so there is no point in 
> getting them. The only other chips I would use are the FJ parts they 
> cost more but have I2S which occasionally is needed but for most things 
> the MC parts have more than enough I/O, I2C and SPI I use quite often to 
> hook up to Arduino peripherals.
> 
> Difficult decisions ahead, the MSP430 family are nice and clean from a 
> programming point but they have limited speed and may be obsolete in the 
> future, The dsPICs are way faster but although they have a nice 
> instruction set are complex to use due to Harvard Architecture 
> complexities, the AVR devices, are cheap but suffer from low processing 
> power but there are plenty enough for many uses, the Arduino platform is 
> cheap and very expandable.
> 
> Then there is ARM for high end applications that need high processing 
> power or low cost. ST has a Nucleo F4 CPU that runs at 180MHz with 512K 
> of Flash, 128K of RAM and tons of I/O for $10.33, that is a ridiculous 
> amount of performance for little money.
> 
> I keep resisting using the ARM for small projects but I am hoping that 
> FF would be useful enough for me to use it as a consistent platform for 
> the PIC18F, dsPICs, and Arduino boards I have and want to use up.
> 
> A thought, how much of the resources are available to the programmer on 
> the AVR versions for FF, I have a ton of Arduinos with the ATMEGA328P 
> parts, and have a few of the 2560 versions also? I did not find that 
> information although it might be in the source files.
> 

Also on the Atmega the memory is mapped into 16-bit address space.
So on the ATMEGA328P all the memory can be used.
On the 2560 approx 50 Kbyte of flash can be used for code and constants.
The X@ X! can be used for fetching and storing in the whole flash memory.

Mikael

[toc] | [prev] | [next] | [standalone]

#47084

On 5/13/2016 8:36 AM, Mikael Nordman wrote:
> On Friday, May 13, 2016 at 12:19:22 AM UTC+3, Cecil - k5nwa wrote:
>> On 5/12/2016 2:50 PM, Mikael Nordman wrote:
>>> On Thursday, May 12, 2016 at 8:23:38 PM UTC+3, Cecil - k5nwa wrote:
>>>
>>>> I had a question for you on FlashForth.
>>>>
>>>> On the dsPIC version how much FLASH can the compiler handle?
>>>>
>>> FF maps the I/O, ram and flash into a 16 bit address space.
>>> On the EP series the address space is divided like this:
>>> I/O , 4 Kbytes
>>> RAM , 16 KBytes
>>> FLASH , the rest 64-16-4 = 44 Kbytes (uses 66 Kbytes of the flash).
>>>
>>> Outside the 16-bit address space 12 KB of flash is used by the EP series for
>>> EEPROM emulation for TURNKEY, DP, IDP and LATEST
>>>
>>> On the the FJ series the address space is divided like this:
>>> I/O , 2 Kbytes
>>> RAM , 16 KBytes
>>> FLASH , the rest 64-16-2 = 46 Kbytes (uses 69 Kbytes of the flash)
>>>
>>> FJ series uses 6 KBytes of flash for the EEPROM emulation.
>>>
>>> With X@ and X!n you can store and fetch data in the whole
>>> 24 bit Flash address space.
>>>
>>> If you wonder why 44 KBytes of addressable data flash uses
>>> 66 Kbytes of flash memory, that is because as program flash there
>>> is an extra byte of flash used for one word address.
>>> So when microchip sells a 128 Kbytes device,
>>> only 2/3 of the flash is available in the data address space.
>>> This is good to know, but FlashForth handles this so you don't
>>> need to care that much.
>>>
>>> The EP series can run on 70 MIPS, but to achieve that it uses a small pipeline.
>>> The FJ series (40 MIPS) does not use a pipeline.
>>> So the EP line is better for running MAC operations without any branches,
>>> while the FJ series is better for a subroutine threaded forth, because the
>>> call/ret pair is twice as fast.
>>>
>>> OTOH, FlashForth inlines quite a lot of code so the effect if the pipeline
>>> is not that big.
>>>
>>> Then of course your choice of chip depends on the peripherals you want...
>>>
>>>
>>>> I ask as I'm getting ready to put in an order on Mouser and I didn't
>>>> want to order chips that will not work or use all the FLASH.
>>>>
>>>> I was looking at the following SPDIP chips;
>>>>
>>>> DSPIC33EP128GP502-I/SP with 128K of FLASH and 16KB of RAM
>>> Works, I have used the 256 Kbyte variant.
>>>
>>>>
>>>> DSPIC33EP128MC202-I/SP with 128K of FLASH and 16KB of RAM This one is
>>>> the #1 choice for most projects due to cost and capability.
>>> Works just as well.
>>>
>>>>
>>>> DSPIC33EP512MC202-I/SP with 512K of FLASH and 48KB of RAM
>>> Should work also.
>>> There may be only 12 Kbytes FLASH available for the compiler,
>>> but you can configure the border between addressable RAM and FLASH
>>> to anything you want.
>>>
>>> BR Mikael
>>>
>> Up to this point I was not aware of all these limits partly due to using
>> a Pascal Compiler which took care of all these items for me so I was
>> ignorant of them, and likely they are not mapping the various memory
>> spaces together so these limits are likely not there at all.
>
> A 32-bit FF could access all flash.
> A 16-bit FF where flash addresses would be two cells long could be another approach.
> But one point with FF was to keep things simple and concise for the user and as similar as possible  over the different architectures.
> Therefore I have stayed with the 16-bit data and code space, and the mapping of the memory spaces.
>
> OTOH you can fit a lot of code into the available flash space.
> My applications have never been so large, that I would have run out of code space.
>
>
>>
>> In any case, with FF then some of the extra space could be used to
>> implement a disk of sorts but not to store active code?
>
> The extra space can also be used for library code by tuning
> the linker scripts. That was done for the floating point
> implementation, it calls the Microchip C-compiler library code.
>
>> It turns out
>> that the DSPIC33EP128MC202-I/SP is the cheapest part, parts with the
>> 64KB and lower FLASH are actually more expensive so there is no point in
>> getting them. The only other chips I would use are the FJ parts they
>> cost more but have I2S which occasionally is needed but for most things
>> the MC parts have more than enough I/O, I2C and SPI I use quite often to
>> hook up to Arduino peripherals.
>>
>> Difficult decisions ahead, the MSP430 family are nice and clean from a
>> programming point but they have limited speed and may be obsolete in the
>> future, The dsPICs are way faster but although they have a nice
>> instruction set are complex to use due to Harvard Architecture
>> complexities, the AVR devices, are cheap but suffer from low processing
>> power but there are plenty enough for many uses, the Arduino platform is
>> cheap and very expandable.
>>
>> Then there is ARM for high end applications that need high processing
>> power or low cost. ST has a Nucleo F4 CPU that runs at 180MHz with 512K
>> of Flash, 128K of RAM and tons of I/O for $10.33, that is a ridiculous
>> amount of performance for little money.
>>
>> I keep resisting using the ARM for small projects but I am hoping that
>> FF would be useful enough for me to use it as a consistent platform for
>> the PIC18F, dsPICs, and Arduino boards I have and want to use up.
>>
>> A thought, how much of the resources are available to the programmer on
>> the AVR versions for FF, I have a ton of Arduinos with the ATMEGA328P
>> parts, and have a few of the 2560 versions also? I did not find that
>> information although it might be in the source files.
>>
>
> Also on the Atmega the memory is mapped into 16-bit address space.
> So on the ATMEGA328P all the memory can be used.
> On the 2560 approx 50 Kbyte of flash can be used for code and constants.
> The X@ X! can be used for fetching and storing in the whole flash memory.
>
> Mikael
>
Thanks, I have some 128K FLASH dsPICs (DSPIC33EP128MC202-I/SP), Nucleo 
Boards, and dsPIC development boards on order, and 20 Arduinos, I have a 
store and put some for sale. But I have some Arduinos UNOs, and 2560 in 
stock and will try FF out later this afternoon, and maybe a dsPIC 
version if I can find the development board.

The biggest pain to dealing with several development system is that 
often the JTAG/Programmers sometimes clash and Windows fail to sort them 
out so for now I stick to a PC for each kind. I have a bunch of HP6000 
PCs that I bought for less than $50 each with Quad Core CPUs that are 
there for that reason, one for each chip type, ARM, PIC, AVR, and a KVM 
switch so they all fit on a table to with room left over.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#47086

On Friday, May 13, 2016 at 5:44:56 PM UTC+3, Cecil - k5nwa wrote:
> Thanks, I have some 128K FLASH dsPICs (DSPIC33EP128MC202-I/SP), Nucleo 
> Boards, and dsPIC development boards on order, and 20 Arduinos, I have a 
> store and put some for sale. But I have some Arduinos UNOs, and 2560 in 
> stock and will try FF out later this afternoon, and maybe a dsPIC 
> version if I can find the development board.

There are precompiled hex files available in the git repository for the Arduino UNO (328/328P) and the Arduino Mega(2560).

Tried to make it easy for beginners. I also sell 328 DIP chips for the UNO that has FF programmed into the chip.

Mikael

[toc] | [prev] | [next] | [standalone]

#47091

On 5/13/2016 10:01 AM, Mikael Nordman wrote:
> On Friday, May 13, 2016 at 5:44:56 PM UTC+3, Cecil - k5nwa wrote:
>> Thanks, I have some 128K FLASH dsPICs (DSPIC33EP128MC202-I/SP), Nucleo
>> Boards, and dsPIC development boards on order, and 20 Arduinos, I have a
>> store and put some for sale. But I have some Arduinos UNOs, and 2560 in
>> stock and will try FF out later this afternoon, and maybe a dsPIC
>> version if I can find the development board.
>
> There are precompiled hex files available in the git repository for the Arduino UNO (328/328P) and the Arduino Mega(2560).
>
> Tried to make it easy for beginners. I also sell 328 DIP chips for the UNO that has FF programmed into the chip.
>
> Mikael
>
I stock ATMEGA329P in my small store, and make programming available. I 
you don't mind I will make the Arduinos available with FF flashed in, 
and the chips also, right now persons can select one of several Arduino 
software versions.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web