mecrispForth for ARM Cortex M0/M3/M4
172 views
Skip to first unread message
holi
Nov 26, 2013, 10:49:24 PM11/26/13
to figt...@googlegroups.com
Dear ArmForth group,
I want to announce Mecrisp-Stellaris, a standalone Forth for ARM Cortex M0/M3/M4 which generates native code with constant folding, inlining of short words and it opcodes common instructions. Runs out of the box on TI LM4F120, ST STM32F407 and Freescale KL25Z128. Examples, porting hints and a M0 disassembler are included.
http://mecrisp.sourceforge.net/
Best wishes,
Matthias Koch
I want to announce Mecrisp-Stellaris, a standalone Forth for ARM Cortex M0/M3/M4 which generates native code with constant folding, inlining of short words and it opcodes common instructions. Runs out of the box on TI LM4F120, ST STM32F407 and Freescale KL25Z128. Examples, porting hints and a M0 disassembler are included.
http://mecrisp.sourceforge.net/
Best wishes,
Matthias Koch
holi
Dec 3, 2013, 8:34:25 PM12/3/13
to figt...@googlegroups.com
hi Matthias,
> Did you have a good time on the Taiwan FIG meeting ?
Ans: 12 Forthers came from different area of the island to attend the discussion. We spend 6 hours for the seminar. One instructor presented his Raspberry Pi gadget with the possibility controlled by Forth.
The figTaiwan leader showed his Arduino eForth which is developped by Dr. C. H. Ting. The group members help to improve it to be able to enter Chinese command. One new forther presented his first step into forth by way of ASYST -- an old but sophisticated scientific software written in Forth. I'm the
obligation to offer my tricky Forth (tF) development sysytem to show all the assembler+disassemble+
decompiler+xcompiler. One other guy discussed the way to control the microcontroller through internet
and celler phone. Lots of interesting things around. We here now encourage forthers to use stm32F4xx
as the vehicle to develop Forth program. One company donated 50 pieces of this board for helping the
promotion. We also get a big amount of donation from other enterprise to support the running of figTaiwan. We also discussed the big annual activity to be held next month. By the time we have to provide the paper or some sort of articles concerning Forth to fullfill the big event. I am cordinally invite you to summit a script to raise the quality of this upcoming conference. In exechange I'll pass some good stuffs to you for helping the promotion of Forth to the world. We really did have a good time while gathering together with Forthers.
> I am a bit puzzled - have you choosen a new name ? Is Albert=Holi ?
While I were in the discussion classroom of the university, I've no wifi to transfer my files to you and the others, I borrowed the computer belongs to Albert to send the files. That's it. So me is holi.
holi === high output low input. ( becoming poor ) <--- my name
hilo === high input low output ( becoming rich ) <-- a company's name
BR holi
Hi Holi, Hi Albert !
Thank you for the notes from the FIG-Taiwan meeting. I am glad that I have choosen the STM32F407 as one of the initial example targets for Mecrisp-Stellaris - if you write peripheral Forth examples for it or a port to another chip, as Albert has done before, I would like to include this into the main release.
You have been using Mecrisp for MSP430, too ? Surely you are familiar with constant folding and small optimisations, but one thing new in Mecrisp both for MSP430 and Cortex M is Flash memory handling. I would love to know if this enriches your conference. Feel free to translate in your native language.
The classical dictionary structure that links from the newest one back to the oldest one has the drawback that the pointer to the newest definition has to be stored in a secure place.
Flash in Mecrisp is linked backwards, with the oldest dictionary entry pointing to the newer one and with the link field of the current definition left blank to be filled in by next invocation of create.
I will do an example to show how it works: Take care on "Address" and "Link" :-)
This is dictionary in Ram. It has standard "forward" linking, with its oldest entry pointing to Flash-Core.
Address: 3A8 Flags: 0 Link: 380 Code: 3B0 Name: ende
Address: 380 Flags: 0 Link: 34A Code: 38A Name: anfang
Address: 34A Flags: 0 Link: 334 Code: 35A Name: ausgehendes
Address: 334 Flags: 0 Link: DAD2 Code: 344 Name: einkommendes
If you don't want to use Ram-Definitions or to make this invisible, FIND just starts in the Core.
Core parts, that will never be changed:
Address: DAD2 Flags: 0 Link: DAEC Code: DADA Name: ?key
Address: DAEC Flags: 0 Link: DB08 Code: DAF4 Name: key
Address: DB08 Flags: 0 Link: DB1E Code: DB10 Name: emit
[much more...]
Address: FD9E Flags: 81 Link: FDC0 Code: FDAE Name: irq-watchdog
Address: FDC0 Flags: 81 Link: FDE2 Code: FDD0 Name: irq-timerb1
Address: FDE2 Flags: 81 Link: 8000 Code: FDF2 Name: irq-timerb0
Link of last Core definition is always start of changeable flash dictionary space.
There is located either $FFFF with freshly erased flash or the header of the first added definition.
Address: 8000 Flags: 10 Link: 8016 Code: 8006 Name: (
Address: 8016 Flags: 10 Link: 802C Code: 801C Name: {
Address: 802C Flags: 10 Link: 8040 Code: 8032 Name: \
They link to the newer one...
Address: 877E Flags: 42 Link: 8876 Code: 8788 Name: cordic
Address: 8876 Flags: 42 Link: 888A Code: 887E Name: sine
Address: 888A Flags: 42 Link: 88A2 Code: 8894 Name: cosine
Address: 88A2 Flags: 40 Link: FFFF Code: 88A8 Name: pi
Link of current definition is unset, to be filled in later.
FIND starts serching in RAM and halts for the firts hit,
and if unsuccessfull, it continues to search in Flash.
In Flash (which is sensed by adress ranges), FIND always searches the whole Dictionary until it finds a $FFFF-Link or $FFFF on the place a link points to. Then it gives back the last hit found. So redefinitions are ok with backlinking.
On Reset, the current/latest definition can be found by going through the links. Free space for HERE is found by looking through flash memory back from the end until something different from $FFFF is found. This has one small quirk: You must ensure that definitions do not terminate with $FFFF - which would be recognized as free space on next Reset and overwritten.
In CREATE one has to take care where to insert the link - but you see clearly now :-) ?!
In my opinion, it would be interesting to see how this idea could fit into a traditional implementation - would you like to try it out while working on CamelForth ? You would have to change the initialisation of pointers, FIND, CREATE and take care of the header macro that builds the core. I hope this would fit Flash memory better, but it has to prove in more traditional environment, too. I came to this idea for myself - do you know of someone else who did this before ? I haven't found one, altough this problem is common for Flash-MCU based implementations.
The next corner to cut will be ram management - the pointer catching routine simply has one "variable pointer" that starts on the end of ram. Words like variable and 2variable are marked as "need ... words of ram". The pointer catching just has to subtract these memory needs from the pointer on startup. New variable definitions in flash decrement the variable pointer accordingly and hardcode the address it points to afterwards. As this gives the same results every run, you don't need to save this pointer, too. It is even possible to carefully erase some definitions from the end of dictionary and simply reset.
Mecrisp also offers initialised variables by letting the pointer catching copy the data after the first ret instruction of the definition marked as "needs ram" to the allocated ram locations - this feature almost comes for free.
Pointer catching needs some cycles - Mecrisp sets its clock to 8 MHz AFTER that to give slowly rising power rails a change. Then, find is invoked to search for occurences of init in dictionary...
Best wishes,
Matthias
Thank you for the notes from the FIG-Taiwan meeting. I am glad that I have choosen the STM32F407 as one of the initial example targets for Mecrisp-Stellaris - if you write peripheral Forth examples for it or a port to another chip, as Albert has done before, I would like to include this into the main release.
You have been using Mecrisp for MSP430, too ? Surely you are familiar with constant folding and small optimisations, but one thing new in Mecrisp both for MSP430 and Cortex M is Flash memory handling. I would love to know if this enriches your conference. Feel free to translate in your native language.
The classical dictionary structure that links from the newest one back to the oldest one has the drawback that the pointer to the newest definition has to be stored in a secure place.
Flash in Mecrisp is linked backwards, with the oldest dictionary entry pointing to the newer one and with the link field of the current definition left blank to be filled in by next invocation of create.
I will do an example to show how it works: Take care on "Address" and "Link" :-)
This is dictionary in Ram. It has standard "forward" linking, with its oldest entry pointing to Flash-Core.
Address: 3A8 Flags: 0 Link: 380 Code: 3B0 Name: ende
Address: 380 Flags: 0 Link: 34A Code: 38A Name: anfang
Address: 34A Flags: 0 Link: 334 Code: 35A Name: ausgehendes
Address: 334 Flags: 0 Link: DAD2 Code: 344 Name: einkommendes
If you don't want to use Ram-Definitions or to make this invisible, FIND just starts in the Core.
Core parts, that will never be changed:
Address: DAD2 Flags: 0 Link: DAEC Code: DADA Name: ?key
Address: DAEC Flags: 0 Link: DB08 Code: DAF4 Name: key
Address: DB08 Flags: 0 Link: DB1E Code: DB10 Name: emit
[much more...]
Address: FD9E Flags: 81 Link: FDC0 Code: FDAE Name: irq-watchdog
Address: FDC0 Flags: 81 Link: FDE2 Code: FDD0 Name: irq-timerb1
Address: FDE2 Flags: 81 Link: 8000 Code: FDF2 Name: irq-timerb0
Link of last Core definition is always start of changeable flash dictionary space.
There is located either $FFFF with freshly erased flash or the header of the first added definition.
Address: 8000 Flags: 10 Link: 8016 Code: 8006 Name: (
Address: 8016 Flags: 10 Link: 802C Code: 801C Name: {
Address: 802C Flags: 10 Link: 8040 Code: 8032 Name: \
They link to the newer one...
Address: 877E Flags: 42 Link: 8876 Code: 8788 Name: cordic
Address: 8876 Flags: 42 Link: 888A Code: 887E Name: sine
Address: 888A Flags: 42 Link: 88A2 Code: 8894 Name: cosine
Address: 88A2 Flags: 40 Link: FFFF Code: 88A8 Name: pi
Link of current definition is unset, to be filled in later.
FIND starts serching in RAM and halts for the firts hit,
and if unsuccessfull, it continues to search in Flash.
In Flash (which is sensed by adress ranges), FIND always searches the whole Dictionary until it finds a $FFFF-Link or $FFFF on the place a link points to. Then it gives back the last hit found. So redefinitions are ok with backlinking.
On Reset, the current/latest definition can be found by going through the links. Free space for HERE is found by looking through flash memory back from the end until something different from $FFFF is found. This has one small quirk: You must ensure that definitions do not terminate with $FFFF - which would be recognized as free space on next Reset and overwritten.
In CREATE one has to take care where to insert the link - but you see clearly now :-) ?!
In my opinion, it would be interesting to see how this idea could fit into a traditional implementation - would you like to try it out while working on CamelForth ? You would have to change the initialisation of pointers, FIND, CREATE and take care of the header macro that builds the core. I hope this would fit Flash memory better, but it has to prove in more traditional environment, too. I came to this idea for myself - do you know of someone else who did this before ? I haven't found one, altough this problem is common for Flash-MCU based implementations.
The next corner to cut will be ram management - the pointer catching routine simply has one "variable pointer" that starts on the end of ram. Words like variable and 2variable are marked as "need ... words of ram". The pointer catching just has to subtract these memory needs from the pointer on startup. New variable definitions in flash decrement the variable pointer accordingly and hardcode the address it points to afterwards. As this gives the same results every run, you don't need to save this pointer, too. It is even possible to carefully erase some definitions from the end of dictionary and simply reset.
Mecrisp also offers initialised variables by letting the pointer catching copy the data after the first ret instruction of the definition marked as "needs ram" to the allocated ram locations - this feature almost comes for free.
Pointer catching needs some cycles - Mecrisp sets its clock to 8 MHz AFTER that to give slowly rising power rails a change. Then, find is invoked to search for occurences of init in dictionary...
Best wishes,
Matthias
holi於 2013年11月27日星期三UTC+8上午11時49分24秒寫道：
holi
Dec 3, 2013, 8:54:38 PM12/3/13
to figt...@googlegroups.com
hi Matthias,
I'm so grateful to yor contribution to the forth community especially in Cortex Mx stuffs.
Here I'll present you with the disassembled + decompiled list of mecrispForth LF120. See if you'd like this style of list or not. Or, is this offend the copyright of your code. Can I publish it publicly?
best regard holi
Hi Holi,
thank you for the nice disassembler listing ! I have some questions: Is your disassembler written in Forth itself ? May I ask for its sources ? I am very interested to include your M3/M4 disassembler as contribution in the mainstream Mecrisp-Stellaris package. For now, I have only done a M0 disassembler myself.
The assembler source code of Mecrisp-Stellaris is published under GPL3 - you can publish the disassembler listing under the same licence, and I kindly ask you for providing a link to http://mecrisp.sourceforge.net/ for those interested in it.
Best wishes from Germany,
Matthias
thank you for the nice disassembler listing ! I have some questions: Is your disassembler written in Forth itself ? May I ask for its sources ? I am very interested to include your M3/M4 disassembler as contribution in the mainstream Mecrisp-Stellaris package. For now, I have only done a M0 disassembler myself.
The assembler source code of Mecrisp-Stellaris is published under GPL3 - you can publish the disassembler listing under the same licence, and I kindly ask you for providing a link to http://mecrisp.sourceforge.net/ for those interested in it.
Best wishes from Germany,
Matthias
Hi Matthias,
I'm very execited to receive your reply. The nswer s are as following...
> thank you for the nice disassembler listing ! I have some questions: Is your >disassembler written in Forth itself ?
AND THE ACCOMPANYING FILE IS THE EXECUTING FILE THAT RUNS UNDER windows XP, try it to see if you can succede in running the program in windows 7 or up.
see depth
I'm very execited to receive your reply. The nswer s are as following...
> thank you for the nice disassembler listing ! I have some questions: Is your >disassembler written in Forth itself ?
Ans: Yes, the disassembler was written under win32forth 4.2.67x from
Tom Zimmer.
Tom Zimmer.
>May I ask for its sources ? I am very interested to include your M3/M4 >disassembler as contribution in the mainstream Mecrisp-Stellaris package.
>For now, I have only done a M0 disassembler myself.
Ans: The M3 disassembler is included in my development system only with no M4.
The source code for the whole development system are not matured enough, so not now..
But I'll present the disassembler to you to see.
This disassembler was generated automatically while assembling. It's kind of tricky.
>The assembler source code of Mecrisp-Stellaris is published under GPL3 - you >can publish the disassembler listing under the same licence, and I kindly ask you >for providing a link to http://mecrisp.sourceforge.net/ for those interested in it.
Ans: I'll do that as far as I can.
Ans: I'll do that as far as I can.
>Best wishes from Germany,
>Matthias
Ans: Ths same to you. I'm from Taiwan
>Matthias
Ans: Ths same to you. I'm from Taiwan
By the way, the monthly FigTaiwan meeting will be held tomorrow,
I'll pass this message to the forthers here in Taipei, Taiwan.
AND THE ACCOMPANYING FILE IS THE EXECUTING FILE THAT RUNS UNDER windows XP, try it to see if you can succede in running the program in windows 7 or up.
Rename it to 4tF733.exe and run it.
On success just type h to see the command line instructions.
h <cr>
h0~h15 cls words' see type u om md mm ao eL st icf dnq oo dsv' map DH DT rmdr ss uart 16x L LLL ic mx ax dbg
see depth
see dup
h1
see dup
h3
see dup
h15 see dup
h0 see dup
t: square push.LR dup * . ret
see aquare
t: 4+ t+4 ret'
see 4+
you can extend your program under this system by just following the same way above. Good luck to you! And thanks again.
Finally you can save the new program as 1.hex by just typing it as "1.hex"
holi
try new things .......
h15 cls words'
h3 cls words'
h1 cls words'
hi Matthias,
holi
Dec 4, 2013, 8:26:01 PM12/4/13
to figt...@googlegroups.com
以下所提執行檔不完全能工作( it runs "a bit" and fails often ) 只有 SEE 可以 , 不知有誰無此問題?.
cannot compile anything ? 我自做自測無問題 可能是系統關係, 我是在 windows XP 下.
Very interesting - to have both x86 and Cortex-M3 code intermixed.真的有趣嗎?還是有用?
M3 disassembler running inside of the microcontroller 只有大容易記憶體才能
I am looking forward to see your final disassembler sources 已經做了只是在pc側,值得在target做嗎?assembler呢?
M3 disassembler running inside of the microcontroller 只有大容易記憶體才能
I am looking forward to see your final disassembler sources 已經做了只是在pc側,值得在target做嗎?assembler呢?
Hello Holi,
it is quite complicated for me to get your executable to run, it doesn't work on Solaris at all and it is difficult to run within Wine environment on Debian Linux, it runs "a bit" and fails often with exceptions. I cannot compile anything, for example, but fortunately, SEE works and I have seen my own special definitions like movwmovt, included. Very interesting - to have both x86 and Cortex-M3 code intermixed.
My goal is to have the M3 disassembler running inside of the microcontroller, that calls for a much smaller disassembler.
Good luck, and I am looking forward to see your final disassembler sources.
Matthias
it is quite complicated for me to get your executable to run, it doesn't work on Solaris at all and it is difficult to run within Wine environment on Debian Linux, it runs "a bit" and fails often with exceptions. I cannot compile anything, for example, but fortunately, SEE works and I have seen my own special definitions like movwmovt, included. Very interesting - to have both x86 and Cortex-M3 code intermixed.
My goal is to have the M3 disassembler running inside of the microcontroller, that calls for a much smaller disassembler.
Good luck, and I am looking forward to see your final disassembler sources.
Matthias
holi於 2013年11月27日星期三UTC+8上午11時49分24秒寫道：
阿貴 albert
Dec 5, 2013, 3:49:51 AM12/5/13
to 符式協會
因為Matthias是在Linux 下用 Wine 去執行 WinFORTH程式，所以應是這系統的問題。
我在Win7 , Win8 中執行是ok的。
--
您已訂閱「Google 網上論壇」的「符式協會」群組，因此我們特別傳送這封郵件通知您。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 figtaiwan+...@googlegroups.com。
如要在此群組張貼留言，請傳送電子郵件至 figt...@googlegroups.com。
請前往以下網址造訪這個群組：http://groups.google.com/group/figtaiwan。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。
BR.
阿貴 Albert
chang luke
Dec 5, 2013, 8:22:00 AM12/5/13
to figt...@googlegroups.com
所以即使給他 source code 也是無法工作 , 相信其他 forther 也有此問題 無交集 .
幸好多數人還是用 win7 / 8 是吧 . 到底還有誰有試過成功的 ?
寄件者： 阿貴 albert <lu.a...@gmail.com>
收件者： 符式協會 <figt...@googlegroups.com>
寄件日期： 2013/12/5 (週四) 4:49 PM
主旨： Re: [符式協會:4975] Re: mecrispForth for ARM Cortex M0/M3/M4
收件者： 符式協會 <figt...@googlegroups.com>
寄件日期： 2013/12/5 (週四) 4:49 PM
主旨： Re: [符式協會:4975] Re: mecrispForth for ARM Cortex M0/M3/M4
因為Matthias是在Linux 下用 Wine 去執行 WinFORTH程式，所以應是這系統的問題。
我在Win7 , Win8 中執行是ok的。
--以下所提執行檔不完全能工作( it runs "a bit" and fails often ) 只有 SEE 可以 , 不知有誰無此問題?.cannot compile anything ? 我自做自測無問題 可能是系統關係, 我是在 windows XP 下.Very interesting - to have both x86 and Cortex-M3 code intermixed.真的有趣嗎?還是有用?
M3 disassembler running inside of the microcontroller 只有大容易記憶體才能
I am looking forward to see your final disassembler sources 已經做了只是在pc側,值得在target做嗎?assembler呢?Hello Holi,
it is quite complicated for me to get your executable to run, it doesn't work on Solaris at all and it is difficult to run within Wine environment on Debian Linux, it runs "a bit" and fails often with exceptions. I cannot compile anything, for example, but fortunately, SEE works and I have seen my own special definitions like movwmovt, included. Very interesting - to have both x86 and Cortex-M3 code intermixed.
My goal is to have the M3 disassembler running inside of the microcontroller, that calls for a much smaller disassembler.
Good luck, and I am looking forward to see your final disassembler sources.
Matthias
holi於 2013年11月27日星期三UTC+8上午11時49分24秒寫道：Dear ArmForth group,
I want to announce Mecrisp-Stellaris, a standalone Forth for ARM Cortex M0/M3/M4 which generates native code with constant folding, inlining of short words and it opcodes common instructions. Runs out of the box on TI LM4F120, ST STM32F407 and Freescale KL25Z128. Examples, porting hints and a M0 disassembler are included.
http://mecrisp.sourceforge.net/
Best wishes,
Matthias Koch
您已訂閱「Google 網上論壇」的「符式協會」群組，因此我們特別傳送這封郵件通知您。
如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 mailto:figtaiwan%2Bunsu...@googlegroups.com。
如要在此群組張貼留言，請傳送電子郵件至 figt...@googlegroups.com。
請前往以下網址造訪這個群組：http://groups.google.com/group/figtaiwan。
如需更多選項，請前往：https://groups.google.com/groups/opt_out。
BR.
阿貴 Albert
Reply all
Reply to author
Forward
0 new messages