Forum Replies Created

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • tomberek
    Participant
    Post count: 10
    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.

  • tomberek
    Participant
    Post count: 10
    in reply to: Tooling update #2099

    bi-yearly check on progress… anything releasable yet?

  • tomberek
    Participant
    Post count: 10
    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.

  • tomberek
    Participant
    Post count: 10
    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.

  • tomberek
    Participant
    Post count: 10
    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 4

    forth word: +

    virtual stack: 7
    belt: 7 3 4

    The 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.

  • tomberek
    Participant
    Post count: 10
    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.

  • tomberek
    Participant
    Post count: 10
    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.

  • tomberek
    Participant
    Post count: 10
    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.

Viewing 8 posts - 1 through 8 (of 8 total)