collapseos
collapseos copied to clipboard
hsoft
CollapseForth compliance
Hello,
now that Forth is official, let's talk about standardization :p
Thats probably not a hard requirement but it would be good for interoperability if your implementation attempted to follow a known forth standard.
My HC11 is going to follow Forth 2012. It will be easy to achieve because I started from an eForth implementation which is almost or all ANS forth compliant, so changes are minimal (and very interesting for interoperability, btw).
Can you give some details about your plans on this? Thanks.
Yeah, I noticed that you seem to put a lot of emphasis on Forth 2012 compliance in sys11. Until I see a clear benefit (for example, an existing app I'd like to integrate),I don't see the point in putting too much effort there. I implement words as their need arise. That being said, I try to stay as close as possible to Starting Forth and F2012.
I'm planning on integrating the vi-like editor at https://www.complang.tuwien.ac.at/forth/vibe-2.1ans.fs as soon as I have a at-xy working. This will be a good compliance test.
Ha yes Starting Forth, I still have to read that one and buy a copy :)
Well, F2012 is just the latest version of the standard, I dont think it's wise in 2020 to follow a version from 1994 or 1983 :)
And the required changes are not so expensive, but they make sense.
in eForth, the FIND word returns the pointer to code and name of the found word or the name and 0. Then you have to determine if the word is immediate, and compile only.
The way specified in F2012 is much more clever. FIND never return compile-only words in interpretation mode so thats one less flag to deal with by the user, and tells himself if the word is immediate or not. The goal is to isolate the implementation details in find.
I am trying to implement all/most of words in the core standard just to be sure I can run a wide variety of software later. Yes, an editor is one of them, but mine will probably look more like ed than vim :)
Next target will be msp430 in FRAM, so non-volatile words yay! And a real project this time, I am building a small 7-segment watch.
On a more serious note, Collapse OS target machines have constraints that are similar to machines from the 80's. F2012 standard is built around different assumptions and made to run under different constraints. I tend to trust old stuff more than modern stuff.
Agreed, however I still feel it's related to some level of details at this point. The fundamentals are still here and very compact.
We can also say that at soon as you have the required forth words to make anything you like run and you can extend it later, it's fine.
In fact I have also not implemented F2012 words that were not used or useful to reduce the overall size of the ROM.
@f4grx, No need to buy Starting Forth it is freely available as PDF on the internet. https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf
As well as Thinking Forth (same author) https://www.dnd.utwente.nl/~tim/colorforth/Leo-Brodie/thinking-forth.pdf
@hsoft, No need to implement complete F2012 but only the required words for CollapseOS.
One thing I have noticed that may be confusing for users, and is not related to F2012 only.
I see in your documentation blocks (one more of your excellent ideas, btw) that your < word performs an unsigned compare.
However, I believe that most < implementations are signed. The word for unsigned comparison is usually U< . Making < an unsigned compare will possibly be a source of bugs when using third-party definitions.
@Picatout : yes I know, I can read it online, but I would like to get some real books about forth in my shelves :)
@f4grx, C.H. Ting have already implemented eForth on MSP430, All C.H. Ting contributions to eForth are on the following page: http://www.forth.org/OffeteStore/OffeteStore.html
yes I know, I have downloaded it, but the goal is to learn, and eforth has some details I dont like (like separate name/code dic and I have updated some points, (eg, I added DOES> , which is not in eForth). Now it's eforth based only :p Moreover it's not ported on the 430FR5739 that has FRAM (better than flash, byte-accessible and virtually no wear).
@f4grx, I bought a launchpad with FRAM a while ago. My deception was that FRAM require wait cycle over 8Mhz. It doesn't wear out but it is slower than FLASH.
Yes, I remember, but its acceptable for me. I'll be using it for a low-power clock running of a CR2032.
-
Max cpu clock speed is 24 MHz. If high performance is required, the kernel can run from ram.
-
I see in the user manual that the 430FR5739 FRAM is accessed through a two-set cache, that is helpful to improve performance.
It seems that VIBE can't serve as a porting example: it's not open source. I'll have to re-implement a visual editor (unless someone knows of another one).
@hsoft, yes, DurexForth has a vi-like editor, called v, written in Forth. It's open source, but the project is still debating a license for contributions overall. I'm sure you could come to an arrangement if you ask.
The exact source file for the editor is here: V.
Also, I've been trying VIBE a little bit on gforth and (unless I'm missing something), there are a couple of changes to its design that would make it much more usable. For one, piggy-backing on the non-visual editor (for its find mechanism). So having some kind of : command to input an arbitrary forth expression and at the same time having the visual editor share the EDPOS variable with the non-visual one could make some powerful editor at a minimal cost in complexity. Or so I hope...
The wordname trick is nice.
@gitjeff2 oh yes of course! I was forgetting about this one.
But with that inlined asm spruced up, that doesn't bode well for ease of porting.
@hsoft no problem!
He also has a Small C compiler, written in Forth, targeting the C64 too. Unfortunately, the current license isn't free software friendly. Getting the right to fork and modify that code might be a bit more of an uphill battle.
But, hey, it's nice to know C on Forth can be done on an 8-bit machine.