Forum Replies Created
- AuthorPosts
- in reply to: Simulation #3703
Still interested in a minimal bootstrap capability. This is less for the OS support that seems to be the current focus and more for the single-board/coprocessor use case, but something that would be fun to work on. From other posts it seems this is now in the realm of possible.
- in reply to: Tooling update #2099
bi-yearly check on progress… anything releasable yet?
- in reply to: Simulation #1697
@ralphbecket: I am trying to figure out additional ways in which Flom can take advantage of Mill specifics/peculiarities.
On the Forth topic: When can we expect to be able to have access to some tooling. I think talking about it may help pave the way, but nothing beats actually putting ideas into practice.
- in reply to: Simulation #1581
LarryP,
I agree. The more I learn about the Mill the more I feel that trying to shoehorn Forth’s stack-based approach into a Mill environment would be frustrating and not very productive. It would only be useful if one wanted to use existing Forth libraries; not my intent.
So what would a higher-level language look like coming from the Mill-style of computing? The immutable values remind me of Functional languages. Items falling off the belt remind me of automatic GC. I did think about writing an interpreter for the Mill Instruction set in Haskell, paramaterized of course by the family-member specifics.
- in reply to: Simulation #1568
I’ve been thinking about the proper way to get Forth onto the Mill architecture. Like you said, the operations/words are the easy part, once the double stack system is set up.
My idea was to steal from the cheap
call
in the Mill to serve the function of the return stack (though we lose the ability to abuse the return stack for other needs). The data stack makes me think of the belt. colorForth uses an 8 item circular buffer, but is for a different use case. Does the compiler keep track of the virtual stack like this:virtual stack: 3 4
belt: 3 4forth word: +
virtual stack: 7
belt: 7 3 4The belt seems to be much more along the lines of a purely functional language where GC is cheap; whenever something falls off the belt. Here I am torn between:
1) Move towards having a Forth where the stack effects are known and verified at compile time. This allows the compiler to keep track of the “virtual” stack. Compiler manages and saves items to a software defined stack otherwise.
1b) use the scratchpad for the remainder of the stack.
2) keep is a “small” Forth: only use the belt, words CANNOT use more than the belt or temp usage of the scratchpad. Restricted, but simple.
3) go very simple; words use the belt+scratchpad, but words themselves are responsible for putting everything onto a software defined stack. This is simpler, but slower as everything has to go through indirection.
4) Deviate from Forth stack-based concept and use a belt-based concept.
I would enjoy trying these and building upon them. And any suggestions would be appreciated.
- in reply to: Simulation #1548
My idea was to learn Forth by bootstrapping it from scratch, I thought it would make sense to try it with the Mill.
- in reply to: Tooling update #2101
I will be happy to explore various paradigms and compiler approaches. I doubt I will be of much use with the low-level design; rather I will be trying to absorb/learn as much as possible. My interests would be in the Forth approach we discussed last year and anything related to Haskell. I may also be interested in assisting with low-level BIOS/drivers, but I have less experience and will need a mentor for that.
Fair disclosure: I would consider the Mill to be a part-time project due to job/family/time considerations.
- in reply to: Simulation #1570
Sounds like (1b). I’ll call that approach “juggling the stack”. The compiler statically keeps track of the stack state and occasionally interrupts the normal flow with stack management. With small enough words, the juggling can all be accomplished during call/return’s.
- AuthorPosts