* [COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers [not found] ` <20230101014054.GD5825@mcvoy.com> @ 2023-01-01 17:21 ` Adam Thornton 2023-01-01 17:33 ` Lars Brinkhoff 0 siblings, 1 reply; 3+ messages in thread From: Adam Thornton @ 2023-01-01 17:21 UTC (permalink / raw) To: Larry McVoy, COFF > On Dec 31, 2022, at 6:40 PM, Larry McVoy <lm@mcvoy.com> wrote: > > All true except for the Forth choice. It's as bad, maybe worse, as > choosing Tcl for your language. I've written a ton of Tcl but I > need the Tk GUI part so I put up with Tcl to get it. I'd never > push Tcl as a language that other people had to use. Same thing > with Forth. > > I dunno what I'd pick, Perl in the old days, Python now (not that > I care for Python but everyone can program it). Just pick something > that is trivial for someone to pick up. (Moved to COFF) I rather like FORTH. Its chief virtues are that it is both tiny and extensible. It was developed as a telescope control language, as I recall, and in highly constrained environments gives you a great deal of expressivity for a teeny tiny bit of interpreter code. I adored my HP 28S and still do: that was Peak Calculator, and its UI is basically a FORTH interpreter (which also, of course, functions just fine as an RPN calculator if you don't want to bother with flow control constructs). But I also make the slightly more controversial claim that FORTH is just LISP stood up on end. These days I think the right choice for those sorts of applications would be Micropython. Yes, a full-on Python interpreter is heavyweight, but Micropython gives you a lot of functionality in (comparatively) little space. It runs fine on a $4 Pi Pico, for instance, which has IIRC 256KB RAM. And if you find yourself missing TCL, there's always Powershell, which is like what would happen if bash and TCL had a really ugly baby that just wouldn't shut up. The amazing thing is that access to all the system DLLs makes it *almost* worth putting up with Powershell. Adam ^ permalink raw reply [flat|nested] 3+ messages in thread
* [COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers 2023-01-01 17:21 ` [COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers Adam Thornton @ 2023-01-01 17:33 ` Lars Brinkhoff 0 siblings, 0 replies; 3+ messages in thread From: Lars Brinkhoff @ 2023-01-01 17:33 UTC (permalink / raw) To: Adam Thornton; +Cc: COFF Adam Thornton wrote: > I rather like FORTH. Its chief virtues are that it is both tiny and > extensible. It was developed as a telescope control language, as I > recall It had a history before that, but yes that was it's first killer app. ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <Y7C50dGWZ6yFDX74@mit.edu>]
[parent not found: <DBC89F53-9A0A-4B34-A627-A9CFF5013EC3@planet.nl>]
[parent not found: <20230101212609.yjg2poiggil7pwat@illithid>]
* [COFF] Re: Porting the SysIII kernel: boot, config & device drivers [not found] ` <20230101212609.yjg2poiggil7pwat@illithid> @ 2023-01-02 9:37 ` Ralph Corderoy 0 siblings, 0 replies; 3+ messages in thread From: Ralph Corderoy @ 2023-01-02 9:37 UTC (permalink / raw) To: coff Hi Branden, > Paul Ruizendaal wrote: > > That was my immediate pain point in doing the D1 SoC port. > > Unfortunately, the manufacturer only released the DRAM init code as > > compiler ‘-S’ output and the 1,400 page datasheet does not discuss > > its registers. Maybe this is a-typical, as I heard in the above > > keynote that NXP provides 8,000 page datasheets with their SoC’s. ... > I don't think it's atypical. I was pretty annoyed trying to use the > data sheet to program a simple timer chip on the ODROID-C2 ... > OS nerds don't generally handle procurement themselves. Instead, > purchasing managers do, and those people don't have to face the pain. ... > Data sheets are only as good as they need to be to move the product, > which means they don't need to be good at all, since the people who > pay for them look only at the advertised feature list and the price. I think it comes down to the background of the chip designer. I've always found NXP very good: their documentation of a chip is extensive; it doesn't rely on referring to external source code; and they're responsive when I've found the occasional error, both confirming the correction and committing to its future publication. On the other hand, TI left a bad taste. The documentation isn't good and they rely on a forum to mop up all the problems but it's pot luck which staffer answers and perennial problems can easily be found by a forum search, never with a satisfactory answer. My guess is Allwinner, maker of Paul's D1 SoC, has a language barrier and a very fast-moving market to dissuade them from putting too much effort into documentation. Many simpler chips from China, e.g. a JPEG encoder, come with a couple of pages listing features and some C written by a chip designer or copied from a rival. In my experience, chip selection is done by technical people, not procurement. It's too complex a task, even just choosing from those of one supplier like NXP, as there is often a compromise to make which affects the rest of the board design. That's where FPGAs have an allure, but unfortunately not in low-power designs. -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-01-02 9:38 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> [not found] ` <CAEoi9W4Np=Z80NdO60x4rEPY6qKaRKYq81aCZxLXX2LAD-9iCA@mail.gmail.com> [not found] ` <CAC20D2O-fUbrCuvvzEj2Z4b2kV+J6TApYdBeMcWvPEADN-nL7w@mail.gmail.com> [not found] ` <CAEoi9W4_ZwOst9yo2GiM4qO4EwapEFia9X7kDZjwQUuhxaEVVw@mail.gmail.com> [not found] ` <CAC20D2NpQdY+oRj-qK45=LR6GuLR3w7ZVmu9SWBd4s6v_Mvepw@mail.gmail.com> [not found] ` <alpine.BSF.2.21.9999.2301011017150.95173@aneurin.horsfall.org> [not found] ` <CAKzdPgzcPVdm_x+WxG7VpssNY7fbr-c2S1ax4S9UOgPPDapOrQ@mail.gmail.com> [not found] ` <CAKr6gn1b=JoNm-9a3iPrHr4QeOzLGFD=Zy6E47YXi6fX4ZGoaA@mail.gmail.com> [not found] ` <20230101014054.GD5825@mcvoy.com> 2023-01-01 17:21 ` [COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers Adam Thornton 2023-01-01 17:33 ` Lars Brinkhoff [not found] ` <Y7C50dGWZ6yFDX74@mit.edu> [not found] ` <DBC89F53-9A0A-4B34-A627-A9CFF5013EC3@planet.nl> [not found] ` <20230101212609.yjg2poiggil7pwat@illithid> 2023-01-02 9:37 ` [COFF] " Ralph Corderoy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).