2026-06-22 01:55:07 <forthBot    > Environment for cleobuline inactive, freeing...
2026-06-22 05:09:38 <deadmarshal > Forth books: https://gist.github.com/fogus/9a10655943421c3cec489f94d6723d58
2026-06-22 07:39:07 <veltas      > pyzozord: https://www.youtube.com/watch?v=mvrE2ZGe-rs
2026-06-22 07:41:47 <veltas      > pyzozord: https://www.youtube.com/watch?v=eEqgZp-VSgs
2026-06-22 07:43:01 <veltas      > First video is better
2026-06-22 07:43:16 <veltas      > Second video is mine
2026-06-22 07:53:36 <Stalevar    > : TEST-STRING S" This is a test string.\n" ;  ok
2026-06-22 07:53:36 <Stalevar    > : rev ( addr u -- ) dup locals| length | 0 do dup 1 - length + i - c@ emit loop drop ;  ok
2026-06-22 07:54:23 <Stalevar    > I was trying to do things in forth and found a weird bug
2026-06-22 07:54:32 <Stalevar    > Which I can't reproduce anymore
2026-06-22 07:56:39 <Stalevar    > : TEST-STRING S" This is a test string.\n" ; redefined TEST-STRING   ok
2026-06-22 07:56:39 <Stalevar    > TEST-STRING TYPE This is a test string.\n ok
2026-06-22 07:56:39 <Stalevar    >   ok
2026-06-22 07:56:55 <Stalevar    > The code to mutate the string was correct and if I do this again, I get correct output
2026-06-22 07:57:07 <Stalevar    > But by then I got some mess of incorrect UTF-8 instead
2026-06-22 07:59:33 <Stalevar    > Big numbers encode "You shouldn't mess with memory" except last one which I didnt use
2026-06-22 09:47:26 <veltas      > Should use ?DO in case the length is zero
2026-06-22 09:48:25 <veltas      > Can use 1- instead of 1 - (but that is preference)
2026-06-22 09:48:54 <veltas      > I don't think you can mix DO..LOOPs with locals, as they're both implemented on the return stack, although I could be wrong about that
2026-06-22 09:51:18 <veltas      > Yeah certainly ANS says so
2026-06-22 09:53:27 <veltas      > There's no guarantee you can write to S" strings compiled into a colon defintion
2026-06-22 09:54:50 <veltas      > In this case I suspect overwriting the bounds of the string is messing up TEST-STRING from running right
2026-06-22 09:55:26 <veltas      > As it may be stored inline in the colon word
2026-06-22 09:56:49 <Stalevar    > veltas, at least when length matched (32 bytes), overwriting worked
2026-06-22 10:05:09 <veltas      > Cool
2026-06-22 10:05:32 <veltas      > That sounds right
2026-06-22 10:07:14 <Stalevar    > But I somehow managed to bring gforth into weird state where it printed 24 as O and some address as G, while overwriting didn't work. I suspect I might somehow set input base to non-decimal
2026-06-22 10:15:44 <veltas      > Maybe
2026-06-22 10:20:05 <veltas      > When you start overwriting unknown things you can definitely get some weird behavior
2026-06-22 11:13:00 <Stalevar    > tabemann_, https://www.bradrodriguez.com/papers/moving1.htm I was wondering what kind of threaded code did you use
2026-06-22 15:14:06 <Stalevar    > Using jonesforth is masochism, but I at least made it type : TYPE ( addr length -- ) 0 BEGIN 2DUP - WHILE DUP 3 PICK + C@ EMIT 1 + REPEAT CR DROP DROP DROP ;
2026-06-22 15:17:57 <veltas      > My impression of jonesforth is it's counter-productive, based on the conversations I've had with people trying to learn from it
2026-06-22 15:18:38 <veltas      > Which isn't that surprising because I don't know what x86 encodings has got to do with writing a Forth, and all the myriad weeds people get into with it before being able to do anything
2026-06-22 15:19:03 <veltas      > I mean x86 encoding has something to do with forths, but nothing foundational or introductory
2026-06-22 15:19:55 <veltas      > And the troubles I see indicate they've not even read most of Starting Forth and understood it, so it's a bit frustrating
2026-06-22 15:21:23 <lofty       > heh, I suspect my own forth probably looks awful to a more experienced eye
2026-06-22 15:22:13 <Stalevar    > veltas, you mean using it or trying to learn from it? Using? It's masochism compared to gforth, for there's no underflow protection and no line editing. And no DO or even TYPE out of the box. For learning? Well, at least I got it to run my code, it is something
2026-06-22 15:22:18 <deadmarshal > veltas: I heard that OSes separated their address spaces, so jonesforth won't work like he wrote it anymore.
2026-06-22 15:22:37 <Stalevar    > jonesforth works on modern linux with small adjustment
2026-06-22 15:22:43 <veltas      > lofty: I skimmed your Forth and it does look 'awful' in a lot of ways, as you expect.  I know the context behind it so I didn't read into that though.
2026-06-22 15:22:47 <deadmarshal > Plus it doesn't tell you how to do "create does>", which is the harder part i guess
2026-06-22 15:23:02 <veltas      > Stalevar: Trying to learn from the source, I mean
2026-06-22 15:23:11 <deadmarshal > Stalevar: what is that adjustment?
2026-06-22 15:23:16 <Stalevar    > deadmarshal, why do you want to create female deers?
2026-06-22 15:23:28 <veltas      > :P
2026-06-22 15:24:07 <Stalevar    > deadmarshal, < 	gcc -m32 -nostdlib -static $(BUILD_ID_NONE) -o $@ $<
2026-06-22 15:24:08 <Stalevar    > ---
2026-06-22 15:24:33 <deadmarshal > hmm
2026-06-22 15:24:33 <veltas      > lofty: You may have had one of the better experiences because you produced something working.  You may have found it easier to just learn Forth in a more normal way and read Brad Rodriguez's Moving Forth articles
2026-06-22 15:24:34 <Stalevar    > -Wl,-Ttext,0 makes jonesforth immediately segfault
2026-06-22 15:25:06 <lofty       > veltas: I am happy to accept feedback all the same. That's how learning works, right?
2026-06-22 15:25:52 <veltas      > My feedback is comments or at least meaningful names are good, and register names aren't meaningful variable names :P
2026-06-22 15:26:06 <veltas      > But as I said I know why it looks like that
2026-06-22 15:26:44 <veltas      > I think if you wrote a Forth from scratch it would immediately be better to read/maintain, and I would be able to give more constructive feedback
2026-06-22 15:27:07 <veltas      > Although there's no reason to write another Forth unless you've got a reason yourself
2026-06-22 15:27:22 <lofty       > well, "interpreter.s" is the rewritten one, rather than "kernel.s"
2026-06-22 15:28:47 <veltas      > What's your codeberg again?
2026-06-22 15:28:59 <lofty       > https://forge.lightcrystal.systems/lofty/sixtyforth
2026-06-22 15:29:07 <veltas      > Oh right not codeberg, sorry
2026-06-22 15:29:16 <lofty       > forgejo, which is the software both run :p
2026-06-22 15:29:30 <veltas      > I do remember now you saying a friend was hosting it kindly
2026-06-22 15:30:05 <Stalevar    > veltas, I didn't read starting forth and I don't feel like. Troubles I have with Forth is that I forget what I have, like I read BEGIN ... WHILE ... and what it was, END, REPEAT, AGAIN? I already forgot it and that's after I wrote a working code with it 20 minutes ago
2026-06-22 15:30:59 <veltas      > lofty: I think I've mixed your repo up with someone else's, so disregard my feedback
2026-06-22 15:31:22 <veltas      > I think I said last time your code is good apart from the renamed dedicated registers (but that's really preference)
2026-06-22 15:31:31 <veltas      > Apologies!
2026-06-22 15:31:38 <lofty       > ^^;;
2026-06-22 15:32:15 <lofty       > "interpreter.s" is making progress at least; it's at the sort of "RPN calculator" stage
2026-06-22 15:32:22 <lofty       > need to work on strings next, I think.
2026-06-22 15:33:00 <Stalevar    > lofty, your link said you have dubious unicode characters
2026-06-22 15:33:28 <lofty       > eh? it's just plain text
2026-06-22 15:33:47 <Stalevar    > –– in particular is 2013 2013, not --
2026-06-22 15:34:06 <Stalevar    > Line 1267 in interpreter.s
2026-06-22 15:34:37 <veltas      > That's always fun
2026-06-22 15:34:55 <lofty       > 
ACTION blinks

2026-06-22 15:36:15 <Stalevar    > -- is 2D 2D
2026-06-22 15:37:37 <Stalevar    > lofty, are you trying to write your own jonesforth-thing?
2026-06-22 15:37:44 <Stalevar    > Except less comments
2026-06-22 15:38:55 <lofty       > My goal is to write a 4 kilobyte chess program for a competition, so the Forth gets turned into bytecode or such and baked into an image
2026-06-22 15:39:19 <Stalevar    > Somebody wrote a chess program in sed... hm
2026-06-22 15:39:34 <lofty       > there are a number of existing C programs in that competition; it seemed a bit boring to write yet another one.
2026-06-22 15:40:50 <lofty       > anyway, I can only assume that the double en-dash is a result of copy/pasting a stack diagram
2026-06-22 15:40:55 <lofty       > easy enough to fix though.
2026-06-22 15:42:25 <lofty       > Stalevar: should be fixed now
2026-06-22 15:44:21 <veltas      > I wonder where that came from because I can't think of what PDF/web etc would generate en-dash instead of just hyphen
2026-06-22 15:44:53 <Stalevar    > You could test your code for dubious chars by using tr -cd '\011\012\040-\0176' < your-file | wc -c
2026-06-22 15:45:08 <Stalevar    > Tab, line break, space to ~
2026-06-22 15:45:39 <Stalevar    > Or simply file - it should say ASCII text if it's OK
2026-06-22 15:46:26 <veltas      > Which tool complained Stalevar?
2026-06-22 15:46:39 <veltas      > I'm assuming something on your end didn't like the non-ASCII?
2026-06-22 15:46:54 <lofty       > the forgejo page for interpreter.s had a warning for confusables at the top
2026-06-22 15:47:51 <Stalevar    > veltas, web interface complained
2026-06-22 15:50:56 <lofty       > > I wonder where that came from because I can't think of what PDF/web etc would generate en-dash instead of just hyphen
2026-06-22 15:50:58 <lofty       > > the Forth 21-1 draft has the stack diagram ( c-addr u – – nt | 0 ) [sic] for FIND-NAME
2026-06-22 15:51:00 <lofty       > which has en-dashes
2026-06-22 15:51:13 <veltas      > How is that generated?
2026-06-22 15:51:19 <veltas      > Also 21-1 is newer than I've seen
2026-06-22 15:51:23 <veltas      > Is it LaTeX?
2026-06-22 15:51:29 <lofty       > I think so?
2026-06-22 15:52:12 <lofty       > http://www.forth200x.org/documents/ shows it to be LaTeX, yes
2026-06-22 15:54:02 <veltas      > Yeah looks like they'd uploaded some newer versions of the draft now
2026-06-22 15:54:17 <veltas      > I think last I looked was like 2024
2026-06-22 15:55:17 <lofty       > also discovered a stray ·
2026-06-22 15:55:33 <tabemann_   > Stalevar, I did inlined native code, i.e. a variant upon subroutine threading where words may be directly inlined instead of called
2026-06-22 15:57:02 <Stalevar    > tabemann_, so it's basically not threaded code anymore, and the article said it has problem that you can't decompile it easily for SEE
2026-06-22 15:57:40 <tabemann_   > yes, that's why SEE in zeptoforth is a disassembler
2026-06-22 15:58:07 <lofty       > tabemann_: did you measure the performance increase from removing the dispatch? just curious for my own experiments.
2026-06-22 15:58:30 <Stalevar    > Is there an option to keep the source code referenced in compiled word?
2026-06-22 15:58:46 <tabemann_   > lofty, no, I didn't, because I implemented it that way from the very start
2026-06-22 15:59:12 <tabemann_   > Stalevar, no, because space is at a premium and that would be a major waste of space
2026-06-22 16:00:06 <tabemann_   > an additional thing I implemented was constant folding for a small set of pre-defined words
2026-06-22 16:00:08 <Stalevar    > On MCU maybe, but otherwise, I think it might be a good idea to for example have jump instruction around the source text string
2026-06-22 16:00:37 <tabemann_   > e.g. 4 + compiles to ADDS R6, #4
2026-06-22 16:00:59 <tabemann_   > it also applies to CONSTANTs
2026-06-22 16:01:03 <tabemann_   > e.g. if you do:
2026-06-22 16:01:07 <tabemann_   > 4 CONSTANT FOO
2026-06-22 16:01:09 <tabemann_   > FOO +
2026-06-22 16:01:15 <tabemann_   > you also get ADDS R6, #4
2026-06-22 16:01:49 <Stalevar    > So you wanted hardcore optimization
2026-06-22 16:01:52 <tabemann_   > Stalevar, well zeptoforth *is* for microcontrollers
2026-06-22 16:02:11 <tabemann_   > it's not quite as hardcore as Matthias Koch's Mecrisp-Stellaris, but it's close
2026-06-22 16:04:28 <tabemann_   > (Mecrisp-Stellaris IIRC maintains a constant *stack* and has extensible constant folding)
2026-06-22 16:08:42 <Stalevar    > Though it doesn't seem to run on rp2350 or at least it's not mentioned on download page
2026-06-22 16:09:18 <tabemann_   > you mean Mecrisp-Stellaris? no, Mecrisp-Stellaris doesn't run on the RP2350, but Mecrisp-Quintus does
2026-06-22 16:09:47 <lofty       > (funny to think I'm friends with the author of the Hazard3 cores in the RP2350)
2026-06-22 16:10:09 <tabemann_   > I still recommend zeptoforth, though, for the RP2350 because it has baked-in support for multicore on top of ordinary multitasking
2026-06-22 16:10:36 <tabemann_   > whereas I'd be very surprised if Mecrisp-Quintus even compared to zeptoforth in this regard
2026-06-22 16:11:18 <tabemann_   > also, zeptoforth on the RP2350 supports hardware single-precision floating point, which isn't available on the RISC-V side of things
2026-06-22 16:12:37 <lofty       > (Luke's been working on instructions to accelerate soft floating point, so maybe a future chip will have that.)
2026-06-22 16:19:56 <Stalevar    > mecrisp-stellaris-3.0.2/README is a nice general forth reference - list of words one per line which are reasonable to find in most forths
2026-06-22 16:20:36 <Stalevar    > Regarding >r <r, if you do this in imbalanced way you break the interpreter?
2026-06-22 16:20:49 <tabemann_   > I think Mecrisp-Stellaris is a very good Forth -- as I mention, I envy its optimizer -- but in the end I still prefer my own Forth
2026-06-22 16:20:54 <tabemann_   > Stalevar, yes
2026-06-22 16:21:04 <lofty       > using "r>" in interpretation mode is an ambiguous condition
2026-06-22 16:21:23 <tabemann_   > also, at least in zeptoforth, >R R> breaks local variables and DO LOOPs
2026-06-22 16:21:42 <tabemann_   > you *can* mix the, but you have to be extremely careful
2026-06-22 16:21:52 <Stalevar    > Where do local variables go? It's like automatic >R R>?
2026-06-22 16:22:07 <Stalevar    >  local| length |
2026-06-22 16:22:20 <tabemann_   > Stalevar, yeah, local and loop variables in zeptoforth go on the return stack
2026-06-22 16:22:44 <tabemann_   > note that zeptoforth uses { foo bar baz } syntax
2026-06-22 16:22:52 <tabemann_   > with -- introducing a comment until }
2026-06-22 16:23:14 <veltas      > That's my preferred syntax
2026-06-22 16:23:40 <tabemann_   > it allows you to do things like write : my-add { x y -- z } x y + ;
2026-06-22 16:26:03 <tabemann_   > note that zeptoforth also had things like : my-add { D: x D: y -- D: z } x y d+ ;
2026-06-22 16:26:19 <tabemann_   > where D: indicates a double cell
2026-06-22 16:26:33 <tabemann_   > *has
2026-06-22 16:27:12 <tabemann_   > (you can also write it with lowercase d: actually, but I prefer D: to make it stand out)
2026-06-22 16:27:43 <veltas      > Very nice
2026-06-22 16:27:45 <Stalevar    > But what if you want a local variable for mutable thing and you don't want to consume the data stack?
2026-06-22 16:27:46 <tabemann_   > there's also W^ and D^, where the defined locals push their *address* rather than value -- this is useful for creating very small buffers on the fly
2026-06-22 16:27:58 <tabemann_   > local variables can be mutable
2026-06-22 16:28:18 <tabemann_   > : foo 0 { x } 1 to x x ;
2026-06-22 16:28:40 <tabemann_   > (W^ is single-cell, D^ is double-cell)
2026-06-22 16:29:14 <Stalevar    > I know it's not the best way to implement rev, but it's first one which worked : rev ( addr u -- ) dup locals| length | 0 do dup 1 - length + i - c@ emit loop drop ;
2026-06-22 16:29:15 <tabemann_   > note that there is also +TO which *adds* the value to the value in the variable
2026-06-22 16:30:17 <Stalevar    > Ah, got it, you add extra 0 thing to initialize the variable
2026-06-22 16:30:25 <tabemann_   > yes
2026-06-22 16:30:43 <tabemann_   > in zeptoforth there are no uninitialized local variables
2026-06-22 16:30:48 <tabemann_   > unlike in some other Forths
2026-06-22 16:31:28 <Stalevar    >  : rev ( addr u -- ) dup { length } 0 do dup 1 - length + i - c@ emit loop drop ;
2026-06-22 16:31:34 <Stalevar    > So this should work the same
2026-06-22 16:31:49 <tabemann_   > Stalevar, I recommend using ?DO instead of DO there
2026-06-22 16:32:22 <tabemann_   > because what if you pass in an empty string?
2026-06-22 16:32:58 <Stalevar    > do — infinite loop, ?do — drop
2026-06-22 16:33:13 <Stalevar    > but you need to drop addr u if empty
2026-06-22 16:33:35 <tabemann_   > 0 0 DO will loop through all possible values
2026-06-22 16:33:45 <tabemann_   > 0 0 ?DO will skip the block
2026-06-22 16:34:01 <tabemann_   > because ?DO adds an extra compare and branch at the start
2026-06-22 16:34:23 <veltas      > No Stalevar you're using a local in do..loop
2026-06-22 16:34:42 <Stalevar    > So if length=0, it will save a copy in local, consume u with comparison, then drop length
2026-06-22 16:34:44 <veltas      > You can't access length because it's being hidden by the iterator/limit
2026-06-22 16:34:47 <Stalevar    > * drop addr
2026-06-22 16:34:59 <tabemann_   > I really only recommend DO when you *know* you will never have zero iterations and you need to save the extra time by eliminating the compare and branch
2026-06-22 16:35:54 <Stalevar    > I do not intend to print empty strings. And yeah simple do to ?do should work. But veltas, it works in gforth
2026-06-22 16:36:05 <Stalevar    > Let me try the { } version
2026-06-22 16:36:31 <tabemann_   > I should note that gforth is not the end-all and be-all of Forths
2026-06-22 16:37:00 <Stalevar    > : rev ( addr u -- ) dup { length } 0 ?do dup 1 - length + i - c@ emit loop drop ;  ok
2026-06-22 16:37:00 <Stalevar    > : TEST-STRING S" This is a test string.\n" ;  ok
2026-06-22 16:38:04 <Stalevar    > Also I don't get why ok in gforth adds a bunch of spaces when copying
2026-06-22 16:38:27 <tabemann_   > "bunch of spaces"?
2026-06-22 16:39:16 <Stalevar    > tabemann_, 38 trailing spaces in string definition
2026-06-22 16:40:35 <tabemann_   > that's probably it's equivalent of Readline at work
2026-06-22 16:40:58 <Stalevar    > Probably. But readline doesn't do that.
2026-06-22 16:41:13 <tabemann_   > is it actually using Readline though?
2026-06-22 16:43:39 <Stalevar    > $ ldd `which gforth` | cut -d / -f 3,4 | cut -d . -f 1,2 | tr '\n' ' '; echo
2026-06-22 16:43:39 <Stalevar    > 	linux-vdso.so lib64/libffi.so lib64/libltdl.so libm.so libc.so libdl.so ld-linux-x86-64.so
2026-06-22 16:46:07 <veltas      > I think they've got some raw terminal nonsense going on because they're implementing the standard which doesn't work well with the default tty control on most UNIX's
2026-06-22 16:46:20 <veltas      > mark4 ran into the exact same issue making his forth
2026-06-22 16:46:24 <tabemann_   > my thought too
2026-06-22 16:46:41 <tabemann_   > when I implemented earlier Forths of mine for Linux, I used raw terminals for similar reasons
2026-06-22 16:48:05 <tabemann_   > dammit, does cleobuline need three or four connections at once (I haven't counted), while having shoddy Internet so they keep on disconnecting and reconnecting?
2026-06-22 16:48:34 <Stalevar    > It's probably one real connection and ghosts
2026-06-22 16:48:45 <Stalevar    > he should use /nickserv regain
2026-06-22 16:48:49 <tabemann_   > nah, they've got different IP addresses
2026-06-22 16:49:24 <Stalevar    > It could be dynamic IP
2026-06-22 16:49:41 <tabemann_   > it's like cleobuline is connected separately on each machine in their house
2026-06-22 16:49:57 <Stalevar    > Why you wouldn't rename without _?
2026-06-22 16:50:49 <tabemann_   > anyways
2026-06-22 16:51:06 <tabemann_   > it's common to implement CR by sending CRLF, which requires raw terminals
2026-06-22 16:51:40 <tabemann_   > also, printing " ok" *after* the user hits enter without being on a new line requires raw termianls
2026-06-22 16:51:54 <Stalevar    > Though why does it even do that?
2026-06-22 16:52:06 <veltas      > I think the standard requires this
2026-06-22 16:52:14 <tabemann_   > it's also traditional
2026-06-22 16:52:30 <veltas      > The old forths were implemented on raw terminals, before UNIX was popular
2026-06-22 16:53:15 <veltas      > If anything UNIX's handling of terminals is a little bit too magical and confusing to new people
2026-06-22 16:53:17 <Stalevar    > Uhm, why do you care about standard? The point is to make code portable. Printing ok doesn't change code portability. I think it would be better to have a prompt character and if code is OK just not print anything
2026-06-22 16:53:41 <tabemann_   > mostly tradition
2026-06-22 16:53:53 <tabemann_   > some Forths do put "ok" at the *start* of a  line
2026-06-22 16:54:09 <tabemann_   > I honestly don't like UNIX "cooked" terminal handling myself
2026-06-22 16:54:39 <veltas      > I think the whole reason it's like this was to save space in programs, so I don't think there's a good reason for it
2026-06-22 16:54:47 <veltas      > e.g. saving one byte per newline
2026-06-22 16:55:15 <Stalevar    > But sh-$, python>>>, cmd>, zsh% all do that. Forth can do too
2026-06-22 16:55:21 <tabemann_   > cleobuline, can you leave unless you actually are active in here? you keep on leaving and rejoining, spamming the connection
2026-06-22 16:56:37 <tabemann_   > I honestly like ... ok -- it has, well, 'character'
2026-06-22 16:58:39 <tabemann_   > it's unique
2026-06-22 16:58:50 <Stalevar    > Jones Forth' OK is weird. You get it once, right after the startup code is run. Then you type your command on same line
2026-06-22 16:58:55 <veltas      > It's because classic Forth is a conversation, it would start with "HI" to say it's loaded, and reply either "OK" or "xxxx?" if it didn't understand something
2026-06-22 16:59:03 <veltas      > Or an abort message
2026-06-22 16:59:25 <veltas      > So it's not a prompt, it's more like a result or response
2026-06-22 16:59:43 <tabemann_   > yeah, zeptoforth doesn't print "ok" if there's an error
2026-06-22 16:59:59 <lofty       > it would start with "HI" to say it's loaded <--- that's adorable
2026-06-22 17:03:25 <veltas      > Yet another thing explained in Starting Forth
2026-06-22 17:05:40 <Stalevar    > does starting forth exist in fb2 or epub?
2026-06-22 17:06:57 <tabemann_   > cleobuline must be on a cell phone
2026-06-22 17:07:21 <tabemann_   > which would explain the constantly changing IP's
2026-06-22 17:08:03 <tabemann_   > I've only seen Starting Forth in PDF myself
2026-06-22 17:08:16 <tabemann_   > and yeah, PDF is obnoxious on phones
2026-06-22 17:19:05 <tabemann_   > here is it as an EPUB > https://archive.org/download/Starting_Forth/Starting_Forth.epub
2026-06-22 17:26:51 <crc         > an initial implementation of my ilo vm in vhdl, running under ghdl for testing. http://charles.childe.rs/temp/ilo-ghdl.tar.gz https://asciinema.org/a/3U0UXv7NcZBF5xX9
2026-06-22 17:27:32 <crc         > I don't have actual FPGA hardware to test on yet, but it does run under the simulation.
2026-06-22 17:32:09 <tabemann_   > have you tried getting an icebreaker board to test it on?
2026-06-22 17:32:38 <tabemann_   > icebeakers are cheap, as FPGA boards go (mind you, FPGA boards are always going to be more expensive than MCU boards)
2026-06-22 17:36:58 <lofty       > I have very mixed feelings on the Lattice iCE40 series...
2026-06-22 17:39:50 <lofty       > Though I can't say my view is unbiased
2026-06-22 17:55:22 <xentrac     > why mixed?
2026-06-22 17:55:40 <xentrac     > there are certainly MCU boards that cost more than an icebreaker
2026-06-22 17:56:21 <xentrac     > crc: that's great! congratulations!
2026-06-22 17:56:38 <lofty       > xentrac: for context, I work on the open tooling for FPGAs; Yosys, nextpnr, icestorm and the like
2026-06-22 17:57:24 <xentrac     > I appreciate those projects a lot
2026-06-22 17:57:33 <xentrac     > what do you think of APIO?
2026-06-22 17:58:28 <lofty       > iCECube2 has a...lax attitude to correctness that has caused a number of people I know to have designs that silently failed. I do not consider that a good thing.
2026-06-22 17:58:56 <lofty       > we pay more attention to correctness than they do, and pay for it in design area
2026-06-22 18:00:39 <lofty       > an example: the D flip flops in the iCE40 only initialise to zero on powerup. what does icecube2 do if you initialise a register to 1?
2026-06-22 18:00:46 <lofty       > it ignores it.
2026-06-22 18:01:16 <lofty       > and it initialises to zero despite being explicitly initialised to one.
2026-06-22 18:03:48 <lofty       > the iCE40LP/HX was originally designed by SiliconBlue, a startup made up of ex-Altera folk. so the chip looks like an Altera Cyclone IV, and not at all like a Lattice chip.
2026-06-22 18:04:35 <lofty       > (actually, Lattice have their in-house-designed MachXO series which are an iCE40 competitor)
2026-06-22 18:05:58 <tabemann_   > back
2026-06-22 18:07:20 <lofty       > But when SiliconBlue got bought the team quit, so Lattice got the chip but not the people who designed it
2026-06-22 18:07:39 <Stalevar    > At first, when beginners hear the term "computer language," they wonder, "What kind of language could a computer
2026-06-22 18:07:39 <Stalevar    > possibly speak? It must be awfully hard for people to understand. It probably looks like:  976#!@NX714&+  if it looks like anything at all." // Don't some computer languages look like this? At least, dc and J
2026-06-22 18:08:49 <lofty       > And so when they made the iCE40UP series they had no clue what they were doing, and it _shows_
2026-06-22 18:09:33 <lofty       > A design on the iCE40UP5K runs at half the speed of the same design on the iCE40HX8K
2026-06-22 18:09:54 <tabemann_   > I never said that the icebreaker was a *good* FPGA board, just a cheap one, and I spent way more for it that I've ever spent on an RP* or STM32 board
2026-06-22 18:10:20 <tabemann_   > good FPGA boards typically cost significantly more than an icebreaker
2026-06-22 18:10:40 <lofty       > I am good friends with Esden
2026-06-22 18:11:30 <lofty       > but I also think the iCE40UP5K was a very bad choice
2026-06-22 18:11:39 <lofty       > and he kinda agrees with me
2026-06-22 18:12:54 <tabemann_   > (and yeah, Mecrisp-Ice on an icebreaker is *slow*)
2026-06-22 18:15:28 <tabemann_   > btw, is icecube2 Lattice's compiler for the iCE40 series?
2026-06-22 18:18:20 <xentrac     > hmm, I don't know what iCECube2 is
2026-06-22 18:18:48 <xentrac     > oh, it's Lattice's equivalent of icestorm
2026-06-22 18:19:43 <xentrac     > I feel like in general Verilog synthesis is prone to ignoring things the chip can't do
2026-06-22 18:20:24 <tabemann_   > Mecrisp-Ice uses icestorm
2026-06-22 18:20:36 <tabemann_   > that's why I hadn't heard of iCECube2
2026-06-22 18:21:31 <Stalevar    > By the way, PicoCalc is an MCU based pocket computer. but are there full fledged MCU based computers which you can plug a keyboard and display to?
2026-06-22 18:22:41 <lofty       > I suppose I should take it as a good sign that people recognise our tools before theirs
2026-06-22 18:22:42 <Stalevar    > There is Agon Light which has eZ80 and ESP32 for interface audio/video/keyboard
2026-06-22 18:23:42 <tabemann_   > Stalevar, I would say an Adafruit Fruit Jam, which is RP2350-based
2026-06-22 18:23:43 <xentrac     > lofty: well, I'm kind of a free-software chauvinist; I'm not typical of either the population as a whole or of EEs.  I'm not an EE, I just play one on IRC
2026-06-22 18:24:17 <tabemann_   > the RP2350 is designed to talk to DVI
2026-06-22 18:24:24 <lofty       > I'm not an EE either, I just happen to be put in the feet of one often
2026-06-22 18:24:36 <tabemann_   > and the RP2350 (and RP2040) can act as USB hosts
2026-06-22 18:25:53 <tabemann_   > I have code in the works to make zeptoforth support HSTX (which it uses to talk to DVI), but I haven't tested it yet because the mini HDMI-supporting board I got has borked mini HDMI support (it doesn't tie it to HSTX), and last time I checked the Fruit Jam was out of stock
2026-06-22 18:26:20 <lofty       > xentrac: given a choice between a better product where the manufacturer actively ignores us, and a worse product where the manufacturer hired us to make the open source tooling their primary toolchain, which would you pick?
2026-06-22 18:27:02 <xentrac     > lofty: pick for what?
2026-06-22 18:27:32 <tabemann_   > I think lofty's referring to FPGA vendors
2026-06-22 18:27:39 <lofty       > In your position as an "open-source chauvinist" :p
2026-06-22 18:29:20 <tabemann_   > part of that for me depends on whether the manufacturer of the former simply ignores or tries to actively obstruct
2026-06-22 18:29:46 <lofty       > Lattice ignore us. From backdoor channels, that is their official policy.
2026-06-22 18:30:22 <xentrac     > I mean, I guess it depends on the circumstances
2026-06-22 18:31:04 <tabemann_   > one thing is that the FPGA market is very FLOSS-unfriendly overall, especially when compared to the MCU market
2026-06-22 18:31:09 <xentrac     > yes
2026-06-22 18:31:29 <xentrac     > less so than 20 years ago when I first saw Linux boot on an OpenRISC 1000
2026-06-22 18:31:32 <lofty       > which makes it all the more notable when a company actively supports us
2026-06-22 18:32:04 <xentrac     > (I went to an event where this was being shown; I didn't have any part of it)
2026-06-22 18:32:35 <xentrac     > I think a lot of it depends on whether the worse product is good enough for whatever I'm hypothetically trying to do
2026-06-22 18:32:44 <tabemann_   > yeah
2026-06-22 18:33:01 <tabemann_   > if the worse product is still sufficient I'd probably support it
2026-06-22 18:33:39 <xentrac     > like, no amount of active open-source-tooling support is going to let me run VexRiscV on a CPLD
2026-06-22 18:33:57 <lofty       > https://colognechip.com/programmable-logic/gatemate/ <-- full disclosure, I was paid to work on the toolchain for this device. I did describe it as worse, because it is slower than even a UP5K, but it is also much bigger than a UP5K.
2026-06-22 18:34:31 <lofty       > I have in the past described this chip as a UP30K
2026-06-22 18:34:33 <lofty       > :p
2026-06-22 18:34:47 <xentrac     > that's exciting!
2026-06-22 18:35:11 <lofty       > https://github.com/YosysHQ/prjpeppercorn/ <-- fully open device databases
2026-06-22 18:35:16 <xentrac     > I'm not sure what I should think of trying to make an FPGA out of 2-LUTs though
2026-06-22 18:35:46 <lofty       > https://github.com/YosysHQ/prjpeppercorn/blob/main/schematics/cpe/cpe.pdf <-- and they let me reproduce diagrams from their internal documentation to publish publicly
2026-06-22 18:36:45 <lofty       > (maybe "recreate"; the terms were that I could not publish anything verbatim from their diagrams)
2026-06-22 18:37:17 <tabemann_   > cool!
2026-06-22 18:37:30 <lofty       > I'm not sure what I should think of trying to make an FPGA out of 2-LUTs though <-- think of them more as "LUT2 reductions" than LUT2s, necessarily.
2026-06-22 18:37:36 <lofty       > the term they use is "LUT tree"
2026-06-22 18:40:50 <xentrac     > can you buy the chips?  how much do they cost?
2026-06-22 18:41:54 <lofty       > https://www.digikey.co.uk/en/products/detail/cologne-chip/CCGM1A1-BGA324/16087879 <--- £20.13 each; obviously there are bulk discounts, especially when you talk directly to them
2026-06-22 18:43:13 <tabemann_   > from what I know, that's inexpensive already as FPGA's go
2026-06-22 18:43:14 <lofty       > https://www.olimex.com/Products/FPGA/GateMate/GateMateA1-EVB/open-source-hardware <--- with a modest evaluation board for 50 euros
2026-06-22 18:43:25 <lofty       > it definitely is
2026-06-22 18:43:36 <tabemann_   > that's less expensive than what I spent on my icebreaker
2026-06-22 18:46:49 <tabemann_   > whereas, say, an RP2350 costs in the vicinity of $1 USD
2026-06-22 18:46:59 <lofty       > yeah...
2026-06-22 18:48:13 <tabemann_   > bbl
2026-06-22 19:00:00 <xentrac     > you can get microcontrollers for 2¢: https://www.lcsc.com/product-detail/C49173938.html
2026-06-22 19:00:19 <xentrac     > those are definitely cheaper than any current FPGA
2026-06-22 19:01:01 <xentrac     > £20 doesn't sound unreasonable
2026-06-22 19:01:15 <xentrac     > it's more expensive than some Lattice parts
2026-06-22 19:15:36 <Stalevar    > I'm not sure why I am doing this, but I have ported my "program" to Jones Forth
2026-06-22 19:15:51 <Stalevar    > $ echo -en "You shouldn't mess with memory  " | rev | xxd -p -u -c 0 | fold -w 8 | sed s/2020// | dc -e '16i?p?p?p?p?p?p?p?p' | tr '\n' ' ';echo
2026-06-22 19:15:52 <Stalevar    > 31090 1869440365 543716457 1998615411 1701650548 661546092 1970235507 544567129
2026-06-22 19:16:05 <Stalevar    > : BREAK-STRING ( 0 n1 n2... addr -- ) BEGIN OVER WHILE TUCK ! 4 + REPEAT DROP ;
2026-06-22 19:16:05 <Stalevar    > : STRING-WORD S" This should be thirty--two bytes" ;
2026-06-22 19:16:44 <Stalevar    > Jones Forth is more convenient to copy code from because it doesn't add ok
2026-06-22 19:21:06 <Stalevar    > tabemann_, it works in zeptoforth too btw
2026-06-22 19:23:32 <xentrac     > Stalevar: that's great!
2026-06-22 19:36:48 <xentrac     > lofty: this GateMate is pretty exciting news!  thanks for letting me know
2026-06-22 19:37:25 <lofty       > xentrac: ^^;;
2026-06-22 19:38:36 <xentrac     > I wonder how effective the multipliers are.  presumably if you want a 16×16 multiply you need 8×8 of their CPEs, each with a 2×2 multiplier?
2026-06-22 19:38:52 <lofty       > ...you need more than that, actually.
2026-06-22 19:39:01 <crc         > tabemann_: not sure on what fpga I'll be targeting yet
2026-06-22 19:40:15 <lofty       > the actual amount is more akin to 9x12
2026-06-22 19:40:22 <lofty       > (CPEs)
2026-06-22 19:41:14 <xentrac     > that sounds completely reasonable
2026-06-22 19:42:04 <lofty       > the implementation of the multipliers is a bit of a horror story (and I was in charge of writing the code for them)
2026-06-22 19:42:18 <xentrac     > I thought so :-)
2026-06-22 19:42:27 <xentrac     > if you wanted a 20×20 or 24×24 multiply, I'd think this chip would beat the crap out of any Lattice product?  also the 5Gbps serdes is something I think none of the Lattice chips have
2026-06-22 19:42:38 <lofty       > the ECP5-5G series can do them
2026-06-22 19:42:45 <lofty       > (5Gbps SERDES)
2026-06-22 19:43:16 <lofty       > (unfortunately I fear if I tell you how the metaphorical sausage is made w.r.t. the GateMate multipliers you might flee in horror back to the iCE40 /lh)
2026-06-22 19:45:22 <Stalevar    > Not so great, I missed I needed an extra drop
2026-06-22 19:50:08 <xentrac     > oh, I didn't know that about the ECP5!
2026-06-22 19:50:16 <xentrac     > no, no, tell me all about the sausage
2026-06-22 19:50:47 <lofty       > okay, remember that cpe.pdf I linked earlier? you will need that as a reference
2026-06-22 19:51:08 <xentrac     > cpe.pdf?
2026-06-22 19:51:18 <lofty       > <lofty> https://github.com/YosysHQ/prjpeppercorn/blob/main/schematics/cpe/cpe.pdf <-- and they let me reproduce diagrams from their internal documentation to publish publicly
2026-06-22 19:51:29 <xentrac     > in particular I'm curious whether you can choose combinational or pipelined multiplies, and how slow each one is
2026-06-22 19:51:43 <lofty       > combinational only
2026-06-22 19:51:44 <xentrac     > oh there it is
2026-06-22 19:53:55 <lofty       > ...how much of FPGA architecture do I need to explain? or should I explain all of it for the viewers watching at home?
2026-06-22 19:56:14 <lofty       > the first and second pages are very important for comprehending the madness that is about to ensue.
2026-06-22 19:56:16 <xentrac     > well, my understanding is that typically each block of an FPGA contains a LUT with 4 to 6 inputs, which you can program with 16 to 64 bits to compute any combinational logic function of those input bits, and a D flip-flop on its output so you can register the output if you want, and some multiplexers to select the inputs from the outputs of neighboring blocks or from longer-distance buses, and typically
2026-06-22 19:56:22 <xentrac     > some special-purpose carry logic to make wide adders fast
2026-06-22 19:56:59 <lofty       > the GateMate is...a bit different than that, but, you will see it at least _rhymes_ with your description :p
2026-06-22 19:58:44 <xentrac     > they have a helpful block diagram next to "Innovative FPGA architecture" on https://colognechip.com/programmable-logic/gatemate/
2026-06-22 19:59:08 <xentrac     > but it's simplified enough to be pretty vague
2026-06-22 19:59:21 <lofty       > the real diagram for that is page two
2026-06-22 19:59:40 <lofty       > I would know: it has my name in the bottom right corner
2026-06-22 20:00:10 <xentrac     > this is pretty exciting stuff
2026-06-22 20:01:12 <lofty       > I have to admit I do not know how clear it is to an outsider, but I _tried_ ^^;;
2026-06-22 20:01:53 <xentrac     > "propagate" and "generate" outputs tell me I'm looking at lookahead-carry-chain logic
2026-06-22 20:03:03 <xentrac     > I think I'd probably have to spend a few hours with this schematic to understand it
2026-06-22 20:03:29 <xentrac     > I'm sure you invested a lot more than that to develop the understanding to draw it!
2026-06-22 20:03:47 <lofty       > you may see the following pages where I have isolated out functionality
2026-06-22 20:04:16 <lofty       > because C_FUNCTION selects different bits of logic
2026-06-22 20:04:40 <lofty       > (if it starts with C_ it's a bitstream configuration bit. a CPE has 80 of them)
2026-06-22 20:05:18 <lofty       > (I am surprised how much of this is still fresh in my usually-terrible memory)
2026-06-22 20:05:44 <crc         > Running a synthesis on my current design with ice40 as a target indicates 15,282 LUT needed if I'm reading the summary correctly. https://gist.github.com/crcx/2525204fe1f59523ecf07b3506573a15
2026-06-22 20:06:08 <lofty       > crc: yes, you are
2026-06-22 20:06:24 <xentrac     > crc: I didn't know there was an iCE40 big enough for that!
2026-06-22 20:06:35 <xentrac     > lofty: I see
2026-06-22 20:07:03 <xentrac     > aha, it's a Booth multiplier!
2026-06-22 20:07:09 <lofty       > yes!
2026-06-22 20:07:31 <lofty       > ...unfortunately, there is...awkwardness with it
2026-06-22 20:08:12 <xentrac     > haha, do tell
2026-06-22 20:08:20 <crc         > not sure there is
2026-06-22 20:08:26 <lofty       > the GateMate has inverting routing multiplexers
2026-06-22 20:08:49 <lofty       > which means the polarity of a signal depends on the parity of routing multiplexers it has gone through
2026-06-22 20:10:21 <xentrac     > sure, that's a good idea
2026-06-22 20:10:46 <xentrac     > I mean, depending on your mux depth and logic family, but it's *often* a good idea
2026-06-22 20:11:10 <lofty       > what this means is that the inputs of each column alternate in polarity
2026-06-22 20:11:13 <xentrac     > a pain in the ass for the gal who's mapping netlists to it, of course!
2026-06-22 20:11:35 <xentrac     > but it often saves you a gate delay
2026-06-22 20:11:45 <lofty       > it is also physically a bit smaller
2026-06-22 20:11:55 <xentrac     > yeah, in the same cases
2026-06-22 20:12:12 <xentrac     > and at 28nm I guess that kind of matters a lot
2026-06-22 20:13:09 <lofty       > if I told you the code dedicated to handling the multipliers is about 4,000 lines of code, would you believe me?
2026-06-22 20:13:35 <lofty       > sorry. 2,000
2026-06-22 20:13:44 <lofty       > I wrote better code than I remembered
2026-06-22 20:14:03 <crc         > I don't really know much about this.
2026-06-22 20:14:18 <lofty       > and that's okay
2026-06-22 20:14:22 <lofty       > I work in a very niche field :p
2026-06-22 20:15:15 <lofty       > but, well, my website is not https://fieldprogrammable.gay for nothing.
2026-06-22 20:18:20 <lofty       > what this means is that the inputs of each column alternate in polarity <-- so, if you take the 8x8 multiply of, say "wire [7:0] a, wire [7:0] b"
2026-06-22 20:20:16 <lofty       > we have to perform "a[1:0] * b[1:0] + ((-a[3:2] * -b[3:2]) << 2) + ((a[5:4] * b[5:4]) << 4) + ..."
2026-06-22 20:38:54 <xentrac     > lofty: that doesn't sound unreasonable at all
2026-06-22 20:39:16 <xentrac     > I don't think multiplication is actually a very niche field
2026-06-22 20:39:50 <xentrac     > I mean it's maybe not as common and fundamental as, like, muxing or addition
2026-06-22 20:40:08 <xentrac     > but it's been pretty central to digital computation since the beginning
2026-06-22 20:40:22 <lofty       > I think Galois would know more about multiplication over fields than me...
2026-06-22 20:40:24 <xentrac     > what's Sharkey?
2026-06-22 20:40:28 <xentrac     > haha
2026-06-22 20:40:33 <lofty       > (I meant FPGA toolchain development :p)
2026-06-22 20:41:05 <lofty       > xentrac: um, ever heard of mastodon?
2026-06-22 20:42:03 <xentrac     > yeah
2026-06-22 20:42:26 <xentrac     > oh, yeah, FPGA toolchain development is unfortunately pretty niche at the moment.  I'm glad you're doing it!
2026-06-22 20:42:28 <lofty       > five second answer: it's mastodon, don't worry about it
2026-06-22 20:42:52 <xentrac     > does it hog gigs of RAM like Mastodon?
2026-06-22 20:44:26 <lofty       > I mean, it's currently using 3 gigs of RAM, yes.
2026-06-22 20:44:38 <lofty       > there are lighter-weight equivalents
2026-06-22 20:44:50 <lofty       > e.g. https://gotosocial.org/
2026-06-22 20:45:09 <lofty       > but I enjoy the user interface of Sharkey, so that's what I use
2026-06-22 20:45:45 <xentrac     > haha
2026-06-22 20:46:05 <xentrac     > I wonder how small you could get a useful implementation of ActivityPub
2026-06-22 20:46:40 <lofty       > um, Sharkey is based on Misskey, if you've ever heard of the latter
2026-06-22 20:47:40 <lofty       > https://fieldprogrammable.gay/@lofty is me if anybody feels like saying hi
2026-06-22 20:48:09 <lofty       > I restarted sharkey and it's down to a gig of RAM.
2026-06-22 20:49:19 <xentrac     > lofty: eat a banana
2026-06-22 20:49:27 <lofty       > fiiine I'll go buy some
2026-06-22 21:18:12 <lofty       > https://fieldprogrammable.gay/files/c278ed99-8008-43e3-8ccf-80da1e80f9ec.jpg
2026-06-22 21:39:57 <xentrac     > how is the banana?
2026-06-22 21:42:14 <lofty       > hopefully potassium-filled
2026-06-22 21:59:18 <xentrac     > lofty: the more I read about this g8m8 the more exciting it seems.  despite the slowness
2026-06-22 22:01:04 <lofty       > I feel there is still a lot we can do to improve it, but the money kind of ran out ^^;
2026-06-22 22:01:35 <xentrac     > aw
2026-06-22 22:02:01 <xentrac     > crc: it sounds like the g8m8 might be big enough for your design
2026-06-22 22:02:01 <lofty       > also after working on a thing for a year, a rest is maybe nice
2026-06-22 22:02:55 <xentrac     > lofty: so I guess they publish all the timing info they have too?
2026-06-22 22:03:03 <lofty       > Yes
2026-06-22 22:03:20 <crc         > I'm going to experiment for a bit to see if I can reduce the LUT count
2026-06-22 22:03:33 <lofty       > Three voltages, three timing corners.
2026-06-22 22:04:18 <crc         > xentrac: what is g8m8?
2026-06-22 22:04:48 <lofty       > the timings are a bit weird because normally chips get binned by performance, but Cologne Chip are too small for that.
2026-06-22 22:05:07 <xentrac     > crc: "gatemate", the chip lofty has been talking about
2026-06-22 22:05:20 <lofty       > ccgm1 :p
2026-06-22 22:05:58 <lofty       > by the way. #yosys is a thing.
2026-06-22 22:06:11 <xentrac     > yes, ccgm1a1/2 officially :-)
2026-06-22 22:06:12 <crc         > thanks
2026-06-22 22:06:44 <xentrac     > one thing I haven't seen so far in the datasheet: is in-application partial reconfiguration possible?
2026-06-22 22:06:56 <lofty       > xentrac: the dies can be tiled together, so an A2 is two A1 dies
2026-06-22 22:07:12 <lofty       > xentrac: not possible in hardware
2026-06-22 22:07:49 <xentrac     > how hard is reprogramming?  can you frob some pins to get it to load a new bitstream?
2026-06-22 22:08:05 <xentrac     > or is it more like reflashing?
2026-06-22 22:08:07 <lofty       > I mean it's JTAG.
2026-06-22 22:09:32 <xentrac     > surely the chip doesn't load its configuration at powerup from a serial boot chip over JTAG!
2026-06-22 22:09:49 <lofty       > you mean like most FPGAs do?
2026-06-22 22:10:01 <xentrac     > don't they use regular SPI?
2026-06-22 22:10:11 <xentrac     > as opposed to JTAG
2026-06-22 22:11:30 <lofty       > Yes
2026-06-22 22:11:43 <lofty       > You do have DS1001 open, right?
2026-06-22 22:12:07 <xentrac     > yes, that's what I'm reading: https://colognechip.com/docs/ds1001-gatemate1-datasheet-latest.pdf
2026-06-22 22:12:27 <xentrac     > I'm just wondering if runtime reconfiguration is a plausible thing to do, and how long it takes if so
2026-06-22 22:15:30 <lofty       > the datasheet suggests you can connect pins of the FPGA to its own config pins
2026-06-22 22:16:25 <lofty       > but my understanding is that the issue is that the config logic can write data to - iirc the config latches - but not read
2026-06-22 22:32:15 <tabemann_   > back
2026-06-22 22:33:31 <lofty       > wb
2026-06-22 22:35:18 <xentrac     > well, what I mean is that if, to reconfigure the chip, you have to execute a Flash erase and rewrite, not only is it going to be very slow, but it's going to wear out the chip quickly
2026-06-22 22:35:26 <xentrac     > if you're reconfiguring it a few times a second
2026-06-22 22:35:57 <xentrac     > but I don't know if these chips store their configuration data in internal Flash, or load it from off-chip RAM like most FPGAs do
2026-06-22 22:36:08 <lofty       > they load it from off-chip memory
2026-06-22 22:36:21 <lofty       > the chip itself uses latches; reconfiguring it does not damage the chip in any way
2026-06-22 22:36:33 <xentrac     > so you can reset the chip and get it to load a new configuration
2026-06-22 22:36:40 <lofty       > yes
2026-06-22 22:36:43 <xentrac     > if you have an external supervisor of some kind
2026-06-22 22:37:28 <xentrac     > dynamic reconfiguration might be useful for things like SDR or for optimization testing
2026-06-22 22:39:03 <tabemann    > one thing I always wonder about is whether there are chips out there with both FPGA's and MCU cores on the same die, to enable FPGA capability while being faster MCU-wise than a soft core
2026-06-22 22:39:28 <lofty       > yes: Xilinx Zynq comes to mind immediately
2026-06-22 22:39:41 <lofty       > the Altera Cyclone V SoC
2026-06-22 22:40:38 <xentrac     > also, unless what you're doing is research on CPU architectures, a CPU is kind of a terrible waste of FPGA real estate
2026-06-22 22:40:59 <tabemann    > yeah, and terribly slow compared to a non-soft core
2026-06-22 22:41:00 <xentrac     > although maybe you could defend something like SeRV: https://github.com/olofk/serv (200 4-LUTs)
2026-06-22 22:41:10 <xentrac     > not necessarily
2026-06-22 22:41:25 <xentrac     > I mean most microcontrollers run at 48MHz or less, and plenty of FPGAs can hit that
2026-06-22 22:41:35 <xentrac     > though SeRV in particular is guaranteed to be terribly slow
2026-06-22 22:43:58 <tabemann    > but there are microcontrollers that cost $1 USD that will go up to 400 MHz (e.g. the RP2350 can easily overclock that far, even though it is only officially rated for 150 MHz), so unless you're worried about your BoM why use a soft core when you can just use a separate hard core
2026-06-22 22:44:22 <xentrac     > yes, but the vast majority of microcontrollers aren't anywhere near that fast
2026-06-22 22:44:42 <xentrac     > just being a non-soft core doesn't make them fast
2026-06-22 22:45:00 <lofty       > fun meaningless fact: the RP2350 is rated for 151.5151... MHz
2026-06-22 22:45:00 <tabemann    > usually you go for low speed though to save power
2026-06-22 22:45:46 <lofty       > (1 / 6.6 nanoseconds)
2026-06-22 22:46:26 <tabemann    > and in my ignorant opinion I'd bet a slow hard core will use less power than an equally slow soft core
2026-06-22 22:47:12 <xentrac     > I think it's about a 10× factor of power usage, but I haven't done the experiment; maybe lofty has?
2026-06-22 22:47:36 <lofty       > I mean, I won't even try to dispute that a hard core will use less power than a soft core
2026-06-22 22:48:17 <tabemann    > which is good reason to pair a hard core with an FPGA than to use a soft core even when you've got LUT's to spare
2026-06-22 22:48:20 <lofty       > but I will say that my experience is generally that unless you are trying to bitcoin mine on an FPGA, power usage is pretty low either way
2026-06-22 22:48:59 <tabemann    > mmm delicious bitcoins <dives into a swimming pool full of bitcoins>
2026-06-22 22:50:15 <xentrac     > there are many orders of magnitude of "pretty low", ranging from 100nW up to 5W
2026-06-22 22:50:50 <xentrac     > people often cited the Z80's low power consumption as a reason for choosing it, but it uses like 500mW
2026-06-22 22:51:25 <tabemann    > if you really care about power usage these days you use something like an MSP430
2026-06-22 22:52:10 <xentrac     > Ambiq's chips beat the MSP430 by about an order of magnitude while being normal ARMs
2026-06-22 22:52:19 <xentrac     > on power usage
2026-06-22 22:52:25 <tabemann    > interesting
2026-06-22 22:52:34 <lofty       > serv might win on power usage /lh
2026-06-22 22:52:37 <xentrac     > they're using subthreshold logic
2026-06-22 22:53:14 <xentrac     > not sure, SeRV has to use a lot of clock cycles to do anything because it's bit-serial
2026-06-22 22:53:35 <lofty       > there's not much logic to switch though.
2026-06-22 22:53:37 <xentrac     > nope
2026-06-22 22:54:37 <tabemann    > I'm more intrigued by ambiq as if they're beating the MSP430 while using normal ARM it takes away much of the MSP430's raison d'être
2026-06-22 22:54:48 <xentrac     > yes, that's exactly right
2026-06-22 22:56:19 <xentrac     > I suspect that in a lot of cases you can get lower power usage with an FPGA by leaving your CPU powered down almost all of the time, or running it at a very slow clock speed, while the FPGA does most of the work with "hard-wired" logic
2026-06-22 22:58:30 <tabemann    > but saving power by turning off your CPU is something a lot off more mundane CPU's can do, by turning off everything except for booting on a GPIO being taken high or low
2026-06-22 22:58:52 <xentrac     > right
2026-06-22 22:58:56 <xentrac     > most of the obvious cases for this kind of thing are commonly integrated as hardwired peripherals
2026-06-22 22:59:32 <xentrac     > a lot of current MCUs can wake up on a capacitive touch input, for example, or on receiving an I²C packet addressed to their address
2026-06-22 22:59:47 <tabemann    > yeah
2026-06-22 22:59:50 <xentrac     > this involves running the captouch or I²C peripherals all the time while the CPU is powered down
2026-06-22 23:00:45 <xentrac     > it's easy to contrive cases where you'd want something analogous that isn't quite supported by the periperals in your CPU of choice
2026-06-22 23:00:49 <xentrac     > *MCU
2026-06-22 23:01:12 <tabemann    > but you could do the same but better by pairing an FPGA with a hard CPU core you can turn off
2026-06-22 23:01:19 <xentrac     > yes
2026-06-22 23:03:59 <tabemann    > if they made one of these that could compete with a high-end STM32 (e.g. an STM32H7) price-wise I could see a definite market for it
2026-06-22 23:04:10 <tabemann    > even if it didn't have the fastest FPGA or the most LUT's
2026-06-22 23:04:55 <tabemann    > because if you're not using a soft core you don't have to worry about wasting LUT's on CPUage
2026-06-22 23:05:31 <xentrac     > I was saying that using an FPGA in addition to a hardwired CPU could save power, not that wasting LUTs on CPUage was a good idea
2026-06-22 23:05:49 <xentrac     > (again, unless you're doing research on CPU architecture)
2026-06-22 23:05:52 <xentrac     > I think a lot of Microchip's new MCU offerings include four FPGA logic cells?
2026-06-22 23:05:53 <tabemann    > I know you werren't saying that
2026-06-22 23:07:36 <tabemann    > unfortunately, they're Microchip
2026-06-22 23:07:46 <tabemann    > which is like one of the worst MCU manufacturers out there
2026-06-22 23:07:53 <xentrac     > haha
2026-06-22 23:08:05 <xentrac     > what has your experience with them been?
2026-06-22 23:09:30 <tabemann    > my main personal experience with them was investigating writng a Forth for a PIC when I was in high school over 20 years ago and abandoning the idea because their architecture was so god damn awful and their MCU's were so limited, and then years later attempting to compile Flashforth and run it under an emulator with their IDE environment, which I also gave up on
2026-06-22 23:10:04 <xentrac     > yeah, the PIC is not a nice machine
2026-06-22 23:10:21 <xentrac     > I've never tried using their software
2026-06-22 23:10:53 <tabemann    > the ARM toolchain is infinitely superior to Microchip's offerings
2026-06-22 23:11:24 <xentrac     > I think Microchip sells a lot of ARM chips these days tho
2026-06-22 23:12:04 <lofty       > I admit that the classic 8-bit chips are before my time, but I have wondered how architectures like AVR look to people who used those 8-bit chips.
2026-06-22 23:12:10 <tabemann    > as ARM goes I'm either an RPi or STM person; I'd try Nordic though if it weren't for their dev boards being horrifically overpriced
2026-06-22 23:13:34 <tabemann    > there are really two kinds of 8-bitters -- classic flat 16-bit addressing space ones  (often backed up with external bank switching), and weird harvard-addressed MCU's like the ATmega ones
2026-06-22 23:14:01 <xentrac     > I used a lot of 8080, Z80, and 6502 chips when I was a kid, but I never programmed them.  I've read through the instruction manuals, though, and the AVR looks like a dream by comparison
2026-06-22 23:14:25 <xentrac     > I've spent some time reading disassembled AVR code but only programmed it in C
2026-06-22 23:14:46 <tabemann    > the only 8-bitter I've ever actually targeted was the 6502 as a kid
2026-06-22 23:14:53 <tabemann    > the Apple //e was my first machine
2026-06-22 23:15:29 <tabemann    > still remember borrowing books outlining 6502 assembly language from the local library, back when libraries carried such things
2026-06-22 23:15:50 <lofty       > the first assembly language I learned was MIPS, and I know people have really strong opinions about MIPS :p
2026-06-22 23:16:24 <tabemann    > too bad the only assembler I had access to was the mini-assembler, which didn't support labels, equates, or macros, and I never thought of copying down the opcodes from said books and doing hand-assembly
2026-06-22 23:16:35 <xentrac     > I've only looked at MIPS in passing, and it seems okay?
2026-06-22 23:16:54 <tabemann    > I played around with ARM in high school even though I didn't end up doing anything with it then, and learned MIPS in college
2026-06-22 23:17:09 <xentrac     > I mean apparently SGI was able to squeeze a fair bit of performance out of it, so it wasn't too fatally flawed
2026-06-22 23:17:33 <tabemann    > MIPS is nice in many regard, but has some weird design choices like thhe infamous delay slot and integer exceptions for overflow
2026-06-22 23:18:14 <xentrac     > the lack of condition codes was weird at the time but has gone mainstream
2026-06-22 23:18:18 <tabemann    > I remember that the assembler they had us use in school hid the delay slot from us
2026-06-22 23:18:32 <xentrac     > that seems like it would help a lot
2026-06-22 23:19:07 <tabemann    > condition codes made sense when RAM was at a premium, but hurts the ability to optimize more modern CPU's
2026-06-22 23:19:29 <lofty       > Yeah, there's the ".set reorder" option to ask the assembler to deal with delay slots
2026-06-22 23:20:12 <lofty       > Despite growing up on PowerPC Macs, I was never able to comprehend PPC asm
2026-06-22 23:20:22 <tabemann    > and then there's RISC-V, which is essentially the second coming of MIPS
2026-06-22 23:20:56 <lofty       > tabemann: literally; MIPS make RISC-V chips now
2026-06-22 23:21:11 <tabemann    > my second machine was a 68K Mac and I had access to a book on 68000 assembly but never really used it, and then my third machine was a PowerPC Mac but I never learned PPC assembly either
2026-06-22 23:22:38 <lofty       > I know a person who is a die-hard 68k fan. sorry to them, I find 68k really hard to understand because the a* and d* registers are sort of but not quite interchangeable and such
2026-06-22 23:23:11 <lofty       > and my brain thinks in dest, src notation, not src, dest notation
2026-06-22 23:23:50 <lofty       > I did actually learn Itanium assembly, because "if something flopped there had to be a reason for it, right?"
2026-06-22 23:24:03 <xentrac     > I thought the A*/D* split was pretty ingenious
2026-06-22 23:24:12 <xentrac     > what did you think of Itanic?
2026-06-22 23:24:25 <lofty       > unfortunately
2026-06-22 23:24:29 <lofty       > I love IA64
2026-06-22 23:24:40 <xentrac     > aww
2026-06-22 23:24:45 <xentrac     > 
ACTION gives lofty a hug

2026-06-22 23:24:46 <tabemann    > I really learned how to program assembly for ARM, but didn't use it until well over a decade later because I didn't have access to actual ARM hardware, and this was also before the days of JLCPCB
2026-06-22 23:24:49 <xentrac     > I'm sorry
2026-06-22 23:25:05 <lofty       > 
ACTION hugs back

2026-06-22 23:25:23 <tabemann    > just reading about Itanium makes it obvious to me why it flopped (i.e. it's too hard to write a compiler for)
2026-06-22 23:25:47 <lofty       > I did actually get SSH access into someone's Merced machine
2026-06-22 23:26:14 <lofty       > tabemann: also the fact that x86 instructions took ten or more cycles each
2026-06-22 23:27:14 <tabemann    > Intel and HP didn't seem to think that maybe people would still want to run their x86 code
2026-06-22 23:27:37 <lofty       > (Merced did not have a way of getting x86 flags, so they were recalculated after every instruction)
2026-06-22 23:27:49 <tabemann    > and I can picture why they'd take ten cycles to run (because if you're doing dynamic recompilation, how is that supposed to work if writing a compiler is impossible?)
2026-06-22 23:29:30 <lofty       > tabemann: mmm, I've come to the conclusion that you can write a compiler for Itanium, but the technology for that came a decade after the chip.
2026-06-22 23:29:51 <tabemann    > which is too little too late
2026-06-22 23:30:39 <lofty       > tabemann: no, they thought people would still want to run their x86 code. they did not think people would still want to run their PA-RISC code :p
2026-06-22 23:32:55 <tabemann    > of course, the only architecture that has been able to actually replace x86(-64) is ARM
2026-06-22 23:33:30 <tabemann    > but Apple is probably one of the few companies that could pull that off -- even Microsoft tried and failed at that
2026-06-22 23:34:14 <lofty       > I realise a lot of the RISCs were similar, but I still feel bad that a lot of computer architectures were killed by the threat of Itanium, only for Itanium itself to then flop
2026-06-22 23:34:31 <tabemann    > me too
2026-06-22 23:34:45 <tabemann    > and I'm personally not really a fan of x86-64
2026-06-22 23:35:06 <tabemann    > which ultimately supplanted them all, except for ARM
2026-06-22 23:35:49 <tabemann    > who has ops here, because frankly at this point I want a tempban for cleobuline
2026-06-22 23:36:04 <lofty       > Unless you're IBM making chips out of what I can only assume is spite
2026-06-22 23:36:07 <tabemann    > something to make the constant joins and quit stop
2026-06-22 23:37:14 <tabemann    > or in the microcontroller and experimental spaces, RISC-V
2026-06-22 23:39:01 <lofty       > I have written, like, most of an RV core, and talked to Luke Wren, and I've developed Opinions about RV...
2026-06-22 23:39:08 <tabemann    > or other niche microcontroller architectures like PIC, AVR, MSP430, and like
2026-06-22 23:40:32 <tabemann    > I tried porting zeptoforth to RV, but it's on hold because its interrupt model is so different from ARM Cortex-M in an, umm, 'inconvenient' fashion
2026-06-22 23:41:07 <tabemann    > with ARM Cortex-M, as you must know, you get a big vector of interrupt handler addresses, and interrupts are essentially transparent
2026-06-22 23:41:40 <lofty       > mhm
2026-06-22 23:41:52 <tabemann    > with RV, you get three interrupts, and everything but the timer and 'soft' interrupts are 'external', which you have to implement some kind of dispatch scheme on
2026-06-22 23:42:32 <tabemann    > and you have to do everything in software
2026-06-22 23:42:35 <lofty       > which is quite MIPS-esque, although MIPS did a very neat thing with that
2026-06-22 23:43:16 <lofty       > also, there are upcoming things to change how interrupts work
2026-06-22 23:44:50 <tabemann    > apparently almost every RV implementation, including the RP2350, *actually* implements an alternate, unique way of doing interrupts, because the default RV way is too awful
2026-06-22 23:45:22 <lofty       > (the RP2350 RV core is called Hazard3)
2026-06-22 23:45:32 <tabemann    > which is a problem if you intend on writing portable code
2026-06-22 23:46:00 <lofty       > (it's open source)
2026-06-22 23:46:20 <tabemann    > as I'm aware
2026-06-22 23:46:55 <lofty       > ... Though I admit I somewhat struggle to understand Luke's _particular_ flavour of Verilog
2026-06-22 23:48:06 <tabemann    > the default RV way seems to designed with enabling minimal-silicon/LUT implementations and nothing else in mind
2026-06-22 23:48:31 <tabemann    > *seems designed
2026-06-22 23:51:06 <lofty       > "misa" is a sort of good idea that reflects a philosophy that RV itself no longer obeys, and so you can't trust it to mean anything anymore
2026-06-22 23:51:13 <lofty       > For example
2026-06-22 23:51:57 <lofty       > and the result appears to be that RV is growing a "cpuid" equivalent
2026-06-22 23:53:10 <tabemann    > MISA?
2026-06-22 23:53:21 <tabemann    > minimal ISA?
2026-06-22 23:53:43 <lofty       > machine-mode CSRs start with m
2026-06-22 23:54:00 <tabemann    > ah
2026-06-22 23:54:46 <tabemann    > RV seems way more minimal than non-ARMv6-M ARM
2026-06-22 23:55:25 <tabemann    > but even then lacks some things I really wish it had that ARMv6-M has such as decent PUSH and POP/branch instructions (I know these have been added in extensions, yes)
2026-06-22 23:55:43 <lofty       > base RV32I does make me think of very early MIPS in its minimalism
2026-06-22 23:57:50 <tabemann    > another thing... why in the world is SP supposed to be 4 word-aligned?
2026-06-22 23:58:05 <tabemann    > yes, it's strictly speaking not *enforced* by the ISA
2026-06-22 23:58:28 <lofty       > it's funny to think about how Hazard3 is intended to have a "curated RV experience", and it's funny to see which bits are _not_ included in H3
2026-06-22 23:58:36 <veltas      > crc: Good luck with your VHDL ilo
2026-06-22 23:58:39 <tabemann    > but there are multiple places where the ISA is designed with this opinion in mind (e.g. c.addsp, the PUSH/POP extension)
2026-06-22 23:58:55 <lofty       > like the compressed table jump extension
2026-06-22 23:58:59 <veltas      > All the FPGA experts lurking in here!
2026-06-22 23:59:15 <tabemann    > Hazard3 is probably the most popular RISC-V out there
2026-06-22 23:59:37 <lofty       > I think there are still a lot of PicoRV32s out there