[COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers

[COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers

[Adam Thornton]

> 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

[COFF] Re: [TUHS] Porting the SysIII kernel: boot, config & device drivers

[Lars Brinkhoff]

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.

[COFF] Re: Porting the SysIII kernel: boot, config & device drivers

[Ralph Corderoy]

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.