01:12 <lispmacs> hi, I am studying into compiler directives and making your own syntax. I was wondering if Forth has a word specifically for "jump execution to the address on the return/control stack" or if that would be implementation specific. The word `again' seems to have this effect...

01:26 <floatcomplex> FUZxxl: it has some downsides. no hardware floating point, and if you want to use their optimized software floating point support for it it's only free-as-in-beer

01:28 <floatcomplex> the fact that it's a completely open datasheet rather than the usual broadcom behaviour is a step forward of course

01:28 <floatcomplex> i'm going to stick to a single cortex-m4 when i need floating point and a single cortex-m0+ when i don't

01:29 <floatcomplex> putting two cortex m0+ in a single package is frankly kinda weird, i don't really know what their imagined use case is that that's the optimal solution

01:54 <FUZxxl> floatcomplex: huch? Isn't the firmware open source, too?

01:54 <FUZxxl> afaik the idea is to have one processor for your main code and the other for short running low latency stuff

01:55 <FUZxxl> and the M0+ is so small, it's not much effort to put a second one in

01:55 <FUZxxl> there's lots of useful stuff to learn from having a multi processor system

02:47 <Zarutian_HTC> oh and that PlayStation thing with SPUs

03:01 <floatcomplex> FUZxxl: i'm trying to find where in the actual code the offending license is, they may have removed it. their website still has objectionable text on it though

03:02 <floatcomplex> "As Cortex-M0+ lacks a floating-point unit, we have commissioned optimised floating-point functions from Mark Owen, author of the popular Qfplib libraries; these are substantially faster than their GCC library equivalents, and are licensed for use on any RP2040-based product."

06:01 <patrickg> it's their first custom hardware design, so it makes sense not to change too many variables

06:02 <patrickg> Once they're more familiar with spinning out MCUs maybe they'll consider using some RISC-V core

06:02 <floatcomplex> patrickg: change not too many variables from...what exactly?

06:03 <patrickg> from shipping an ARM SoC on a custom board to shipping a custom ARM MCU

06:04 <floatcomplex> patrickg: cortex m0+ has very little to do with cortex a anything

06:05 <floatcomplex> i happen to agree with you that riscv would have been a risc too far, but i don't think "we want to use arm because we did before" is the reason

06:05 <patrickg> they can still lean-in on existing channels, the tooling for verification etc is probably similar

06:06 <floatcomplex> if anything, aarch64 and riscv64 asm look more similar than aarch64 and cortex-m asm do

06:06 <patrickg> even going from cortex-whatever (that is, arm ltd design to plug in) to some custom ARM design would be folly when you're also dealing with creating your own chip for the first time

06:07 <patrickg> get the custom chip made, then look at customizing more parts or changing partners for parts