2022-04-01 00:00:33 <lispmacs    > I got setup recently for SWD debugging with the Pico, so now am exploring GDB remote debugging, ARM assembly, and Mecrisp Forth all at the same time
2022-04-01 00:01:22 <lispmacs    > It is not shown in the post, but I figured out how to load the Mecrisp symbols into GDB also
2022-04-01 00:03:46 <lispmacs    > something I learned in the process was the interesting fact that Mecrisp compiler automatically converts code like "12 +" into a single assembly instruction which adds 12 to the tos register (register r6, in this case)
2022-04-01 00:04:47 <lispmacs    > maybe that is commonly done in Forths, but it was cool to learn that while stepping through the code on the live system
2022-04-01 00:21:42 <MrMobius    > mecrisp is pretty darn amazing. it does a whole lot of optimizing which is not common
2022-04-01 06:47:18 <veltas      > mecrisp is magic
2022-04-01 06:47:32 <veltas      > There's this C killer I've been trying out at work called GCC C
2022-04-01 06:48:34 <veltas      > It's just C but with defined behavior on bit order and stuff where the standard refuses to comment
2022-04-01 06:48:59 <veltas      > And no useless push for stuff nobody wants in the committees or endless conversations about "ABI horror"
2022-04-01 06:50:36 <boru        > You mean GNU C?
2022-04-01 07:35:50 <KipIngram   > I rather like GNU C.
2022-04-01 07:36:09 <KipIngram   > To some extent BECAUSE it goes beyond the standard.
2022-04-01 07:36:27 <KipIngram   > Been a while since I've used it, though.
2022-04-01 07:53:38 <boru        > Yeah, it has some nice things I wish were part of ISO C, like stdfix.h
2022-04-01 07:58:24 <veltas      > boru: No I mean GCC C. So not even the GNU extensions, just the choice of GCC is enough to make 'C' behave more predictably
2022-04-01 07:58:33 <boru        > Aha, right.
2022-04-01 07:58:55 <boru        > I suppose I still agree, so far as freestanding implementations go.
2022-04-01 07:59:05 <veltas      > The only syntax GNU extension I like is block expressions
2022-04-01 08:00:36 <veltas      > Or expression blocks or whatever they're called
2022-04-01 08:03:37 <boru        > There are a few other little nice things, like being able to have variadic macros which can take zero parameters, and being able to have trailing commas and that sort of thing.
2022-04-01 08:03:52 <boru        > Niche feature, but helpful nonetheless.
2022-04-01 08:04:41 <veltas      > Yeah that's good too
2022-04-01 08:05:02 <veltas      > The thing is I also would rather rely on GCC's definition of 'C' than the committee's
2022-04-01 08:05:33 <boru        > The C standard committee has really gone downhill with microsoft and intel putting their oar in.
2022-04-01 08:06:17 <boru        > There was talk of repurposing `auto` for the next revision how it was done in C++, but I'm not sure if that made it in there. It might have made `_Generic` marginally helpful.
2022-04-01 08:06:37 <boru        > Some of the submissions were quite hilarious, though.
2022-04-01 08:08:31 <veltas      > There was a discussion on adding objective C style closures to C
2022-04-01 08:10:41 <boru        > There is a propensity for shoehorning features from other languages into C. IMHO, this goes against the philosophy of the language, and programmers should just go and use those other languages.
2022-04-01 08:14:23 <veltas      > Unfortunately I think we passed the "what's the harm?" stage of adding too much and under-defining C before ANSI C was released
2022-04-01 08:14:57 <boru        > Yeah, and then adding "optional" parts which ultimately made "conformance" meaningless.
2022-04-01 08:15:29 <boru        > C11 has one or two nice features, but what bellend thought that threads was a good addition...
2022-04-01 08:17:01 <KipIngram   > The GNU extension providing pointers to labels is useful.  With that you can make a proper indirect threading "next."
2022-04-01 08:17:50 <KipIngram   > Microsoft and Intel are more interested in setting up advantages for themselves than in fostering the language.
2022-04-01 08:18:01 <boru        > Agreed on that score.
2022-04-01 09:01:45 <veltas      > Anyway C is fine if you stick to a sane subset (fuckin C++ dejavu right now) and just rely on your ABI/compiler implementation choices if you're writing embedded code
2022-04-01 09:03:39 <MrMobius    > one scary thing is when people suggest things that might make life a bit more convenient for them on a PC but horrific for embedded
2022-04-01 09:03:52 <MrMobius    > since after all, if that person doesnt do embedded its not really a thing
2022-04-01 09:04:10 <boru        > Indeed. The C standard submissions ML is chock full of that.
2022-04-01 09:04:54 <KipIngram   > So, re: that embedded address candidate thing I mentioned earlier - it turns out that the ANSI standard reserves portions of the escape sequence pool for "private use."  That's good - that means I could still print strings containing such items to the screen without filtering them, and they'd show up ok - the OS would just ignore that particular sequence.
2022-04-01 09:05:39 <veltas      > It won't necessarily ignore it right? Depending on how 'private' is defined?
2022-04-01 09:06:19 <KipIngram   > Well yeah - I think the idea is that those sequences get "registered" somewhere.  If the string went into something that was already using that sequence for something else, that wouldn't work.
2022-04-01 09:06:43 <KipIngram   > It's possible people have been using those without registering them, so who knows what's out there.  I'd have to test it.
2022-04-01 09:06:56 <KipIngram   > And it would always be vulnerable to future changes.
2022-04-01 09:07:29 <veltas      > MrMobius, boru: IMO VLAs were one of these features. I know lots of people like C99 but I just think VLAs are gross. And you can implement VLAs on embedded but it's even more explosive
2022-04-01 09:07:44 <veltas      > Far too 'clever' for my kind of C
2022-04-01 09:08:07 <boru        > Yeah, plus VLAs are broken by standard.
2022-04-01 09:08:22 <boru        > e.g. if you use them with longjmp, there's no guarantee that they're cleaned up.
2022-04-01 09:08:39 <boru        > (Aside from the obvious problems)
2022-04-01 09:08:55 <veltas      > That's actually weird, longjmp should in theory be able to clean it up
2022-04-01 09:08:55 <KipIngram   > veltas: I guess my main point there is that at least it's not like the entire code pool is saturated with popular functionalities.
2022-04-01 09:09:10 <boru        > I don't remember the exact wording with it, but that was the gist.
2022-04-01 09:09:24 <veltas      > KipIngram: If it's 'private' you don't need to register it though
2022-04-01 09:09:31 <KipIngram   > is not, rather.Never mind - I got it right in the first place.  :-(
2022-04-01 09:09:42 <KipIngram   > Yeah, I found that aspect confusing.
2022-04-01 09:09:50 <KipIngram   > But... it's another "standard."
2022-04-01 09:10:01 <KipIngram   > Likely doesn't make total sense.
2022-04-01 09:10:06 <boru        > VLAs were just added to satisfy fortan users, iirc
2022-04-01 09:10:12 <veltas      > Yeah, fuck standards. I won't pull up my trousers for anybody!
2022-04-01 09:10:15 <boru        > They are useful sometimes, but more often that not, a bad idea.
2022-04-01 09:10:49 <veltas      > That's the problem with committees, you get all these people who want their pet feature
2022-04-01 09:10:55 <boru        > Indeed.
2022-04-01 09:11:04 <veltas      > That's why late FORTRAN, COBOL, and ALGOL suck
2022-04-01 09:11:14 <veltas      > So let's apply the same process to C lol
2022-04-01 09:11:16 <boru        > I mean, can you imagine putting microsoft on the committee, whose C compiler didn't even support C99 for 15 years or some such.
2022-04-01 09:11:52 <veltas      > Which is because they pretty much ignored C for a while, not worth spending money on
2022-04-01 09:12:08 <veltas      > They had loads of legacy code in C but ANSI C was indeed "good enough"
2022-04-01 09:12:46 <boru        > That may be the case, but they had absolutely no business being on the committee.
2022-04-01 09:13:18 <veltas      > I don't want to point fingers but mainly because I think committees as a concept are the problem
2022-04-01 09:13:26 <KipIngram   > ^ that
2022-04-01 09:14:03 <KipIngram   > I've always thought that most of the really brilliant stuff is cooked up by one person, or maybe a couple, with a good vision.
2022-04-01 09:14:10 <veltas      > C was a breath of fresh air when it was new because it was pretty much made by one person
2022-04-01 09:14:20 <KipIngram   > :-)
2022-04-01 09:14:25 <KipIngram   > We're in tune this morning.
2022-04-01 09:26:57 <KipIngram   > I don't know exactly when a collection of people designing something gets "too big."  It may not have to be *one*.  Maybe "a few" can work, but I think that number is pretty low, and certainly when "corporate interests" get injected you may as well just give up on it.
2022-04-01 09:34:04 <veltas      > In my opinion you need someone who can make decisions, but who has good taste and is willing to listen to their counsel
2022-04-01 09:35:51 <veltas      > You're the final judge on matters, have the final say, but you are part of a larger system of people who are at least as smart as you and will inevitably think of stuff you didn't.
2022-04-01 09:36:20 <veltas      > But if it's design by consensus then nobody is steering the ship. Try driving by consensus and see where that lands you!
2022-04-01 09:36:57 <KipIngram   > Yes - that sounds just right.  Groups can work, but someone needs to be the "final aribter."
2022-04-01 09:37:08 <veltas      > Early C was good because it was an iteration of an iteration of very smart people trying hard to simplify ALGOL
2022-04-01 09:37:31 <veltas      > But it was important that one person mostly made the decisions about what made it in and what didn't
2022-04-01 09:38:22 <veltas      > Somebody needs to be at the wheel, it's not a 'principle' it's a bloody necessity lol
2022-04-01 09:46:32 <KipIngram   > Couldn't agree more.
2022-04-01 09:46:58 <KipIngram   > "Kum ba ya" product development just usually doesn't go well.
2022-04-01 09:47:45 <KipIngram   > "No one's the 'boss' - we're a TEAM."  Please - deliver me.
2022-04-01 10:12:21 <KipIngram   > veltas: Also agree with you, though, that "the boss" needs to be one who pays attention to the ideas the team produces and is eager to go with the best one.  Inattentive boss is a bad boss.
2022-04-01 14:18:44 <KipIngram   > So, after researching a little I decided that the safest way to implement that source-embedding of addresses (if I do it at all, it will be in the future, if and when compile time starts to bug me) is to select some strange key pattern that I'll never use (like say alt-tilde) and hijack the associated "assign string to pattern" sequence.  The "string" would just be the decimal representation of the address I
2022-04-01 14:18:47 <KipIngram   > was embedding.
2022-04-01 14:19:28 <KipIngram   > That's an offical standardized sequence that won't ever be "given new meaning," so it's safe to use it.  I tested that out and confirmed that both the compiler (LOAD) and TYPE ignore that pattern.
2022-04-01 14:19:45 <KipIngram   > So, that idea goes in my hip pocket - if I ever need to compile faster, I know what to do.
2022-04-01 14:20:45 <KipIngram   > Meanwhile, my real interest here is in being able to use colors and attributes in my source code - so there I *want* TYPE to respond to the strings, in the usual way, and meanwhile WORD / the compiler will ignore them.
2022-04-01 14:21:20 <KipIngram   > Or rather WORD will filter them out.
2022-04-01 14:22:31 <KipIngram   > That embedded address idea would have a severely adverse effect on source code size.  All those little 1-character core words, + - ! @ etc would suddenly take up 12-15 bytes in the source.
2022-04-01 14:25:56 <KipIngram   > A better way of speeding compile up on core words might be to identify the words I wanted to target (by doing some sort of profiling, ideally) and invest some work in a static hash table for those.  The the overhead wouldn't have to be repeated every single time I put the word in source code.
2022-04-01 14:26:40 <KipIngram   > That wouldn't play well if I wanted to re-use those names in other vocabularies, but like I said last night - that's probably bad policy anyway.
2022-04-01 15:47:21 <lagash      > KipIngram: ever considered writing stuff down in a wiki or blog?
2022-04-01 16:48:32 <KipIngram   > I used to blog a good bit, like 15 years ago.  You could probably dig some of it up on the wayback machine.
2022-04-01 16:48:46 <KipIngram   > I've tried to resume a few times over the years, but somehow have never stuck with it.
2022-04-01 16:48:58 <KipIngram   > I was consulting at the time, so I tended to have more spare time.
2022-04-01 16:49:17 <KipIngram   > And I could tell myself it was "promoting me," though I'm sure it never really did.
2022-04-01 16:52:01 <KipIngram   > Anyway, once I took a "regular job" again I kind of lost my momentum.
2022-04-01 16:56:00 <KipIngram   > That embedded address stuff isn't anything new - I caught onto the general idea in the first place from reading stuff Jeff Fox wrote about stuff  Chuck did.
2022-04-01 16:57:36 <KipIngram   > I set out to write one like that several years ago, but after wading into I realized it had some limitations.  It was hard for me to see how it could support vocabularies well.  I think it made sense to Chuck while he was writing his chip design setup because he was being very Chuck and working toward ONE TARGET.  One application.  Very focused.  I think that word names were unique system wide, and that was
2022-04-01 16:57:39 <KipIngram   > really required to make his specific structure work.
2022-04-01 16:57:53 <KipIngram   > And he got source compression out of it as a bonus.
2022-04-01 16:58:30 <KipIngram   > The only thing in his source was that "address token."  So he had to be able to absolutely trust that token-to-word binding was never going to change.
2022-04-01 16:59:38 <KipIngram   > My guess is that he was re-compiling more or less his entire system, from scratch source code, frequently as he worked.  So he set out to figure out how to speed that up.
2022-04-01 17:00:06 <KipIngram   > The most obvious way was to avoid having to search the dictionary.
2022-04-01 17:00:37 <KipIngram   > I think his words were looked up at source edit time, as he typed them, so the tokens could be accumulated in the buffer he was editing.
2022-04-01 17:00:45 <KipIngram   > Then when he hit "go," it just screamed.
2022-04-01 17:01:50 <KipIngram   > I may have interpreted it wrong - I was just making the best guess I could at how it was structured based on Fox's words.
2022-04-01 18:27:09 <KipIngram   > I see a lot of similar ideas in play between the GA144 and the Transputer from the 1980's.
2022-04-01 18:27:47 <KipIngram   > Though the Transputer was a microcoded design.
2022-04-01 18:33:37 <KipIngram   > I do think that the "array of simple cores" idea is the right one, but I think that the existing software industry back in the last few decades of last century represented inertia for "faster faster faster" instead of "more more more."  So that created economic pressure to invest more and more complexity into individual processor cores, to squeeze every last drop of performance out of them.
2022-04-01 18:34:24 <KipIngram   > We have these nice multicore cpus these days, but they can't really cooperate together well in a fine-grain way because of cache limitations.
2022-04-01 18:35:27 <eris[m]     > i think the big issue with 'array of simple cores' is the like, sofrware side of it
2022-04-01 18:35:46 <eris[m]     > im all for it but no one like, wants to do ether
2022-04-01 18:35:55 <eris[m]     > or design a low level system
2022-04-01 18:36:12 <eris[m]     > there's a lot more barrier to entry the further down you go, you feel?
2022-04-01 18:36:36 <KipIngram   > Right - that's exactly what I meant.  We've never really figured out how to use that type of architecture.
2022-04-01 18:36:49 <eris[m]     > yea
2022-04-01 18:37:08 <eris[m]     > we have no actually usable abstractions beyond possibly erlang's actors + message passing model
2022-04-01 18:37:11 <KipIngram   > It became a self-maintaining cycle - manufacturers made the processors faster, software vendors made the software more dependent on fast single cores.  We've done several rounds of it by now.
2022-04-01 18:37:20 <eris[m]     > but, actors + messaging isn't that good at the low level
2022-04-01 18:37:23 <KipIngram   > Eventually it will tap out.
2022-04-01 18:37:42 <KipIngram   > I don't think the tap out is "immenent," but we can't just keep getting faster forever.
2022-04-01 18:37:43 <eris[m]     > see the challenges the Hubris MCU kernel has with performance
2022-04-01 18:38:06 <eris[m]     > (it uses a message passing model and it can't do anything vaguely high performance)
2022-04-01 18:38:25 <eris[m]     > maybe the existence of actual hardware parallelism would fix that
2022-04-01 18:38:27 <eris[m]     > but eh, it's a bit too complex
2022-04-01 18:38:49 <KipIngram   > And yeah - by now the existing models just have a lot of inertia - no one does the research to figure out the parallel stuff because that's just not the fastest way to get a product ready to sell.
2022-04-01 18:39:02 <KipIngram   > "Do it the way we know how to do it."
2022-04-01 18:39:24 <KipIngram   > I'm not criticizing - it's just economic reality for most businesses.
2022-04-01 18:39:55 <eris[m]     > GPUs already abide by a lots of smple cores method afaik
2022-04-01 18:40:13 <eris[m]     > I wonder if something like APL would be relevant here?
2022-04-01 18:40:16 <KipIngram   > Yes - they had a easy to target application.  Some of those things are just astounding.
2022-04-01 18:40:23 <eris[m]     > I doubt it, but it's been shown to run on GPUs
2022-04-01 18:40:40 <KipIngram   > In that case the data actually "comes apart into pieces" for a lot of purposes.
2022-04-01 18:41:26 <KipIngram   > I'm afraid I don't really know APL.  I should take a look at it - I've certainly heard a lot of positive hype about it over the years.
2022-04-01 18:41:58 <eris[m]     > I'm a K user myself; APL's biggest thing is the programming model and notation
2022-04-01 18:42:05 <KipIngram   > I was reading those etherForth docs yesterday, and noting how thoroughly *different* it would be programming in that context.
2022-04-01 18:42:24 <KipIngram   > The cores are so simple that you simply must find a distributed solution.
2022-04-01 18:42:25 <eris[m]     > yea
2022-04-01 18:42:38 <eris[m]     > i dont think etherforth would take off, tbh
2022-04-01 18:42:57 <KipIngram   > I was struck by the notion that in some ways it's more like designing a digital circuit (at the gate level) than designing software.
2022-04-01 18:43:06 <KipIngram   > The distributed operation, the communication, etc.
2022-04-01 18:43:34 <KipIngram   > I think it would likely take a good bit of practice to get reasonably competent at it.
2022-04-01 18:43:40 <eris[m]     > yea...
2022-04-01 18:43:55 <KipIngram   > But at least etherForth looks like a good "case study," and the source is available for study.
2022-04-01 18:44:32 <eris[m]     > true!
2022-04-01 18:45:34 <eris[m]     > my friend tells me about another possible case study
2022-04-01 18:45:36 <eris[m]     > but its a supercomputer
2022-04-01 18:45:37 <eris[m]     > Tianhe-2
2022-04-01 18:45:50 <KipIngram   > Oh, I haven't heard of that one.
2022-04-01 18:46:19 <KipIngram   > Holy cow.  33.86 petaflops.
2022-04-01 18:46:30 <eris[m]     > information is sparse
2022-04-01 18:46:32 <eris[m]     > but it uses
2022-04-01 18:46:38 <eris[m]     > 260-core manycore processor
2022-04-01 18:47:03 <eris[m]     > The CPE cores feature 64 KB of scratchpad memory for data and 16 KB for instructions, and communicate via a network on a chip, instead of having a traditional cache hierarchy.[5] The MPE's have a more traditional setup, with 32 KB L1 instruction and data caches and a 256 KB L2 cache.[1] Finally, the on-chip network connects to a single system interconnection interface that connects the chip to the outside world.
2022-04-01 18:48:37 <eris[m]     > the approach common for mega parallelism seems to be manager cores
2022-04-01 18:48:38 <eris[m]     > which seems a bit boring?
2022-04-01 18:48:43 <KipIngram   > And 24 Mwatts.
2022-04-01 18:50:16 <KipIngram   > When you start trying to form a network of things that large, the interconnect poses a real issue.  Nearest neighbor is "easy" thing to do, and means you'll only directly communicate with the "periphery."
2022-04-01 18:50:29 <eris[m]     > that's true
2022-04-01 18:50:57 <eris[m]     > but it(being manager systems) leads to a hierarchical arrangement of compute which is just inflexible
2022-04-01 18:51:31 <eris[m]     > surprisingly, i think that message passing would not be a suitable model for this sort of hardware
2022-04-01 18:51:35 <KipIngram   > Yes - sort of back to "we don't know what to do with it" again.  Maybe there just *isn't* a good way, but I don't think we know for sure yet.
2022-04-01 18:52:03 <eris[m]     > at least the supercomputers have a sense of purpose lol
2022-04-01 18:52:24 <eris[m]     > i think the language would end up totally different
2022-04-01 18:52:25 <eris[m]     > and even forth is tainted by this
2022-04-01 18:52:26 <KipIngram   > I wonder if anyone's ever done a careful numerical study of interconnect stats in brains.
2022-04-01 18:52:53 <KipIngram   > Like, how fast does the interconnect density fall off as distance between the neurons goes up?
2022-04-01 18:53:00 <KipIngram   > Because we know brains can do impressive things.