Wondering what kind of effort would it be to port Flashforth to the newest Microchip mid-range exteneded PIC's would be? I would love to be able to access all the new hardware peripherals from Flashforth.
Best,
R.
Last edit: Randall Young 2017-07-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess it would be a fairly small effort. I quess some of the PIC18 stuff could left out, since these have so little memory.
- double wordset
- multitasking
- assembler
The return stack is 16 deep and can handle only 15-bit(?) values. That was not clear from the datasheet.
But I will not do it. In my opinion the device is just too small. And I have many other things I want to do. Do you want to give it a go ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am interested. What I can't see from the documentation is how much memory is used. Could you give a rough breakdown of where the memory goes, so I have some idea of whether a workable system is possible with FF?
These devices seem to have greater memory than the low end 14K50 and similar to 24k55.(more ram if the usb dual port was excluded)
I was mistaken, I thought these devices had only half of that memory.
So currently on the PIC18 flashforth uses 8,5 KBytes of flash, 200 bytes of ram and 20 bytes of eeprom.
A difference compared to 18F is the 15 bit wide R stack which means you need to implement the stack for R> >R R@ using FSR1 in RAM, FSR0 would be used for the parameter stack.
18F has 3 FSR pointers registers.
Flashforth 18F relies on the third FSR(1) register as temp pointer and storage, which the 16F does not have, so you would need to recode those parts differently. For example by having two roles for FSR1.
Actually I am just now updating FF PIC18F to use FSR2 as pointer in ram for the R stack.
It saves a few cycles and uses a bit less code.
A starting point is to compile FF 18F, look at the listing and map files and try to model it all word for word on the 16F resources and instruction set.
These 16F chips instruction set is similar to the 18F, but different :-)
M.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you give me a rough idea of approximately how much of that memory is the runtime, and how much is the compilater/interpreter part.
i.e. In the case of deploying a stable design that will no longer require interactive interpret/compile, what would be the min memory requirement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the programmer hardware. Actually this is how it would be done in production, even when the chip still had the full interpreter - the pics would be duplicated with the full compiled forth load in them. (i.e. you wouldn't first program an empty forth load, then power it up, and download the forth source itself.
The point is to be able to deploy into the smaller devices in production. 7kB or 3.5kB (which makes using 14pin devices possible)
So:
1) How much space does the unused compiler/interpreter take up (i.e. can I go down a memory step in the PIC by dumping it)?
2) How to remove the unused part? (e.g. force unused part to be in high part of memory, and remove it at the hex file level; external compilation instead of internal etc)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My question was just to get a rough idea of just how small a device might be able to run FF without the compilation/interactive/other seldom used features i.e. how small a device might it be potentially useful in in the long term.
I have no interest in writing a cross compiler or tethered system, however a viable technique might be to:
1- force non-runtime code to locate in top of flash
2- load FF into large memory development PIC
3- read hex file from flash using programmer once forth program has been loaded in
4- trim hex file to dump top of flash, and overwrite any specific locations (e.g. vectors, max ram, etc) that need it
5- write to smaller flash PIC for deployment
OR
1- force non-runtime code to locate in top of flash.
2- load FF into large memory development PIC
3- load forth in, debug.
4- Add SHRINKEMBED command that makes any changes to the flash to turn it (permanently) into the runtime small memory version. SHRINKEMBED never returns to flashforth - the part is embedded small memory until reflashed with FF.
5- read hex file from flash using programmer
6- write to smaller flash PICs for deployment
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My guess is that the compiler and interpreter related words takes maybe half of the flash and half of the ram. Too much work to calculate.
Then from the runtime words you could also remove the ones you don't need.
But I think there may be quite some details to consider to shrink the image.
Moving the interpreter/compiler to high memory would be the first exercise.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
First of thanks for a great project!
Wondering what kind of effort would it be to port Flashforth to the newest Microchip mid-range exteneded PIC's would be? I would love to be able to access all the new hardware peripherals from Flashforth.
Best,
R.
Last edit: Randall Young 2017-07-17
Yup, I've been hoping for this also. The PIC16F15345 / 16F18345 hit the hardware sweet spot for me, and forth would be a good fit.
I guess it would be a fairly small effort. I quess some of the PIC18 stuff could left out, since these have so little memory.
- double wordset
- multitasking
- assembler
The return stack is 16 deep and can handle only 15-bit(?) values. That was not clear from the datasheet.
But I will not do it. In my opinion the device is just too small. And I have many other things I want to do. Do you want to give it a go ?
I am interested. What I can't see from the documentation is how much memory is used. Could you give a rough breakdown of where the memory goes, so I have some idea of whether a workable system is possible with FF?
These devices seem to have greater memory than the low end 14K50 and similar to 24k55.(more ram if the usb dual port was excluded)
16F18346 16kWord flash, 2048B ram
16F15345 8kW, 1024B
I was mistaken, I thought these devices had only half of that memory.
So currently on the PIC18 flashforth uses 8,5 KBytes of flash, 200 bytes of ram and 20 bytes of eeprom.
A difference compared to 18F is the 15 bit wide R stack which means you need to implement the stack for R> >R R@ using FSR1 in RAM, FSR0 would be used for the parameter stack.
18F has 3 FSR pointers registers.
Flashforth 18F relies on the third FSR(1) register as temp pointer and storage, which the 16F does not have, so you would need to recode those parts differently. For example by having two roles for FSR1.
Actually I am just now updating FF PIC18F to use FSR2 as pointer in ram for the R stack.
It saves a few cycles and uses a bit less code.
A starting point is to compile FF 18F, look at the listing and map files and try to model it all word for word on the 16F resources and instruction set.
These 16F chips instruction set is similar to the 18F, but different :-)
M.
Can you give me a rough idea of approximately how much of that memory is the runtime, and how much is the compilater/interpreter part.
i.e. In the case of deploying a stable design that will no longer require interactive interpret/compile, what would be the min memory requirement.
How do you deploy a stable design without the interpreter and compiler ?
These are needed for to get the Forth code compiled into the chip ?
With the programmer hardware. Actually this is how it would be done in production, even when the chip still had the full interpreter - the pics would be duplicated with the full compiled forth load in them. (i.e. you wouldn't first program an empty forth load, then power it up, and download the forth source itself.
The point is to be able to deploy into the smaller devices in production. 7kB or 3.5kB (which makes using 14pin devices possible)
So:
1) How much space does the unused compiler/interpreter take up (i.e. can I go down a memory step in the PIC by dumping it)?
2) How to remove the unused part? (e.g. force unused part to be in high part of memory, and remove it at the hex file level; external compilation instead of internal etc)
So you are planning to write a cross compiler or a tethered system.
Good luck with that.
My question was just to get a rough idea of just how small a device might be able to run FF without the compilation/interactive/other seldom used features i.e. how small a device might it be potentially useful in in the long term.
I have no interest in writing a cross compiler or tethered system, however a viable technique might be to:
1- force non-runtime code to locate in top of flash
2- load FF into large memory development PIC
3- read hex file from flash using programmer once forth program has been loaded in
4- trim hex file to dump top of flash, and overwrite any specific locations (e.g. vectors, max ram, etc) that need it
5- write to smaller flash PIC for deployment
OR
1- force non-runtime code to locate in top of flash.
2- load FF into large memory development PIC
3- load forth in, debug.
4- Add SHRINKEMBED command that makes any changes to the flash to turn it (permanently) into the runtime small memory version. SHRINKEMBED never returns to flashforth - the part is embedded small memory until reflashed with FF.
5- read hex file from flash using programmer
6- write to smaller flash PICs for deployment
My guess is that the compiler and interpreter related words takes maybe half of the flash and half of the ram. Too much work to calculate.
Then from the runtime words you could also remove the ones you don't need.
But I think there may be quite some details to consider to shrink the image.
Moving the interpreter/compiler to high memory would be the first exercise.