2022-07-03 10:02:26 <lopata      > Hello, How One can implement Matrixes in Forth ?
2022-07-03 10:03:16 <eris[m]     > depends on how you'll be using them
2022-07-03 10:06:02 <lopata      > mmh
2022-07-03 10:07:08 <lopata      > Its for matrix operations, eigenvectors...
2022-07-03 10:11:25 <lopata      > { { 0 0 1 } { 1 0 1 } { 0 1 0 } } Matrix
2022-07-03 10:11:54 <lopata      > means { row1 row2 row3 }
2022-07-03 10:12:58 <lopata      > and then So one could do  1 1 myMatrix
2022-07-03 10:17:29 <lopata      > also I would like to be able to change a value like
2022-07-03 10:18:09 <lopata      > 4 (val) 2 (row)  3 (col) myMatrix
2022-07-03 10:19:15 <dinklebink  > hello
2022-07-03 10:20:21 <dinklebink  > I've been studying a few programming languages and I had a quick question about forth, do you guys think that compiled C is faster than compiled forth because of the nature of C or because more people have put effort into really complex C compilers
2022-07-03 10:22:59 <KipIngram   > lopata: Like most such things, you have to build the machinery yourself, both for "indexing into" matrices and for "constructing them" using some syntax.
2022-07-03 10:23:50 <KipIngram   > If your matrices will be one size you can hardwire the dimensions into the indexing, but if you want something more generic then you'd need to store the dimensions with the matrix so the indexing code could access them.
2022-07-03 10:25:12 <lopata      > mmh, alright, I was hoping it has been implemented alreay somewhere... Your thoughts... I must do it with CREATE DOES> ?
2022-07-03 10:25:49 <KipIngram   > And you'll probably want to consider some sort of memory management - say you multiply two  matrices; you'll need a place to put the product.  You could allocate that yourself separately and provide a pointer to it, but I think I'd want there to be a way for the system to make that place itself.
2022-07-03 10:26:09 <KipIngram   > Um, well, I don't think you HAVE to - that's just one way of doing it.
2022-07-03 10:26:15 <lopata      > ok very interesting
2022-07-03 10:26:26 <lopata      > thanks Ill give it a try
2022-07-03 10:27:16 <KipIngram   > With create/does the create part would allocate space, maybe copy the dimensions into their holding place, and the does> part would be where those values were accessed and indexing occurred.
2022-07-03 10:27:49 <KipIngram   > If I were going to do it that way, I'd probably just have the "matrix word" take indices and leave the address of that matrix cell.
2022-07-03 10:28:05 <KipIngram   > And then you'd use that address the way you'd use any other.
2022-07-03 10:28:38 <lopata      > yeah, the does> must do the conversion between coordinate and memory
2022-07-03 10:29:17 <KipIngram   > If you use that to create all of the matrices you'll need for a calculation, then no extra memory management would be required.
2022-07-03 10:29:54 <KipIngram   > If you have an assembler you could make a primitive for the indexing and that would be a lot faster.
2022-07-03 10:31:24 <KipIngram   > Also, if you are willing to waste some RAM you could make the row lenghts "the next power of two up," and you could shift instead of multiply for that row length multiplication.
2022-07-03 10:31:35 <lopata      > how can you manage an asm primitive for that?
2022-07-03 10:32:16 <KipIngram   > Uh, well, the indices would be on the stack, so the primitive would just use those to do the indexing calculation.  Kind of the same way any arithmetic primitive works.
2022-07-03 10:32:35 <KipIngram   > Primitives have to be able to get at values on the stack, and have to be able to adjust the stack pointer.
2022-07-03 10:32:43 <KipIngram   > "most of them" do stuff like that.
2022-07-03 10:33:40 <lopata      > I dont have that mucj RAM, im on MSP430
2022-07-03 10:33:53 <KipIngram   > Ah, yeah - on a micro you wouldn't want to throw any away.
2022-07-03 10:33:55 <lopata      > It has to be very compact
2022-07-03 10:34:23 <KipIngram   > Understood - then you eat the multiply time.  But you're doing it for good reason, so...
2022-07-03 10:35:29 <KipIngram   > That was just a side thought - that indexing code will be run a whole lot, so anything that might speed it up would be at least worth considering.
2022-07-03 10:35:44 <KipIngram   > Are you doing some sort of signal processing?
2022-07-03 10:35:47 <KipIngram   > Sounds interesting...
2022-07-03 10:36:13 <lopata      > if all the matrix would have dimension 3x3, do you think it'd be better to convert the index in ternary before storing it
2022-07-03 10:36:56 <KipIngram   > If they're all 3x3 I wouldn't store the dimensions at all; I'd just write the indexing code with hard coded values,
2022-07-03 10:36:57 <lopata      > have it all in a 10 aligned vector, and restore it
2022-07-03 10:37:20 <KipIngram   > And in that case you might consider "dup 2* +" for the multiplication, or its assembly equivalent.
2022-07-03 10:38:09 <KipIngram   > Oh, I see what you mean.
2022-07-03 10:38:32 <KipIngram   > I don't think I would - I think I'd pack 'em in 9 cells, and would do the dup 2* + for the 3 * necessary for indexing.
2022-07-03 10:39:40 <KipIngram   > If you've got source code access to your system and can re-build it you might consider adding a 3*  primitive, that does the dup 2* + in assembly.
2022-07-03 10:39:51 <KipIngram   > That would get you a nice speedup.
2022-07-03 10:40:15 <lopata      > Yeah good idea
2022-07-03 10:40:52 <KipIngram   > Or just add an indexing primitive; dup 2* + +
2022-07-03 10:41:11 <KipIngram   > That would require you to specify <col> <row> instead of <row> <col>, though.
2022-07-03 10:41:32 <KipIngram   > Which might be fine, but I think most folks "think row first" when they think about matrices.
2022-07-03 10:41:42 <KipIngram   > Or maybe you store it by columns.
2022-07-03 10:41:49 <thrig       > but forth is backwards therefore...
2022-07-03 10:41:59 <KipIngram   > Yes, true.
2022-07-03 10:42:02 <lopata      > I think the 3* primitive would do it
2022-07-03 10:42:12 <lopata      > and use it row col
2022-07-03 10:42:39 <KipIngram   > You'd still need to swap first then.  swap 3* +
2022-07-03 10:42:46 <lopata      > I dont want to mess my mind with revertedmatrix index notation
2022-07-03 10:42:49 <KipIngram   > Or say <row> 3* <col> +
2022-07-03 10:43:05 <KipIngram   > Yeah, totally understand.  You WILL forget several times while developing your code.  :-)
2022-07-03 10:43:20 <thrig       > what could possibly go wrong
2022-07-03 10:43:25 <KipIngram   > :-)
2022-07-03 10:43:27 <KipIngram   > EVERYTHING!
2022-07-03 10:43:34 <KipIngram   > At least when you're my age.
2022-07-03 10:44:12 <KipIngram   > lopata: ok, when you started talking 3x3 I stopped thinking signal processing and started thinking robotics.
2022-07-03 10:44:14 <lopata      > For your ask, its not for signal processing, but Im experimenting a Cyclic group over F8
2022-07-03 10:44:21 <KipIngram   > Oh, ok.
2022-07-03 10:44:57 <lopata      > elevated computation sort of
2022-07-03 10:45:12 <lopata      > using matrix instead of booleans
2022-07-03 10:45:28 <KipIngram   > I've thought about building support for finite integer fields into my system someday.
2022-07-03 10:45:38 <KipIngram   > When I get around to stuff that complex.
2022-07-03 10:45:56 <KipIngram   > I want to be able to do Octave/Matlab type stuff, and for that I want something that's "type aware."
2022-07-03 10:46:12 <dinklebink  > yes
2022-07-03 10:46:28 <KipIngram   > Not from the ground level - but I envision having a "modified interpreter" that I can invoke when I want to do that kind of thing, and then "quit" out of to fall back to the original interpreter.
2022-07-03 10:48:00 <MrMobius    > are we talking about MSP430? i think i missed the beginning of the conversation
2022-07-03 10:48:30 <MrMobius    > you can do a3* in three instructions
2022-07-03 10:48:39 <KipIngram   > Yes.
2022-07-03 10:48:56 <dinklebink  > any thoughts on the compiler question?
2022-07-03 10:49:22 <KipIngram   > Oh, sorry - I missed that.  Hang on.
2022-07-03 10:50:05 <KipIngram   > Both, I think, dinklebink.  C *has* received an awful lot of optimization attention, and C compilers are pretty damn good at that these days.
2022-07-03 10:50:17 <MrMobius    > darn connection. i dont have my old laptop logging channels 24/7 anymore
2022-07-03 10:50:28 <dinklebink  > KipIngram, I was thinking about trying to write a game in Forth
2022-07-03 10:50:36 <KipIngram   > But Forth is implemented in various ways - if the Forth you're on is indirect or direct threaded then it's just going to have a bit of overhead.
2022-07-03 10:50:37 <dinklebink  > but I'm a bit worried C would be noticeably faster
2022-07-03 10:50:43 <thrig       > clang has really good error messages, compared to old gcc getting to EOF and going, "whelp, that's that"
2022-07-03 10:51:00 <KipIngram   > A code threaded Forth could in theory be as fast as optimized C, but then the fact that C has gotten more attention will probably let it win.
2022-07-03 10:51:43 <KipIngram   > The "standard strategy," though, is to recognize that your performance is usually set by only about 1% or so of your code - you profile it and then hand optimize that 1%, and if you do that you can probably wind up with a Forth imp that comes awfully close to matching C speed.
2022-07-03 10:51:53 <KipIngram   > That might involve writing a few critical words in assembly.
2022-07-03 10:52:01 <KipIngram   > You use profiling to decide which ones.
2022-07-03 10:52:10 <dinklebink  > but it's not naturally a slower language, it's just that C became the golden child
2022-07-03 10:52:19 <KipIngram   > Yes, I agree.
2022-07-03 10:52:31 <KipIngram   > Though like I said - indirect and direct threading carries a bit of overhead.
2022-07-03 10:52:35 <dinklebink  > if you write Forth with some inline asm you should be able to get very close to C performance
2022-07-03 10:52:39 <KipIngram   > carry
2022-07-03 10:52:50 <KipIngram   > Yes - I agree.
2022-07-03 10:52:58 <KipIngram   > "Most of your code" doesn't matter performance-wise.
2022-07-03 10:53:07 <KipIngram   > Which is why Python can be used to write fast scientific apps.
2022-07-03 10:53:19 <KipIngram   > It invokes optimized libraries for the stuff that really gates the performance.
2022-07-03 10:53:26 <KipIngram   > And Python is a DOG performance wise.
2022-07-03 10:53:56 <KipIngram   > Python is slow, but the numpy library is fast.
2022-07-03 10:54:12 <thrig       > also computers have gotten fast enough that something that maybe wouldn't run well enough on pentium 90 now is fine
2022-07-03 10:54:23 <KipIngram   > That too.
2022-07-03 10:55:07 <KipIngram   > This is why I chose to do my system indirect threaded.  It's the slowest kind of Forth, most of the time, but right from the start I planned to be able to do that profile/optimize thing, so I decided it didn't matter that it was a little slower.
2022-07-03 10:55:14 <KipIngram   > There are other reasons I prefer it.
2022-07-03 10:55:23 <KipIngram   > (one of which is just familiarity).
2022-07-03 10:55:52 <dinklebink  > it's why python and languages like that are often even used in high performance games, for stuff like menus
2022-07-03 10:56:00 <KipIngram   > Exactly.
2022-07-03 10:56:08 <KipIngram   > The "glue" that holds the fast stuff together.
2022-07-03 10:57:26 <dinklebink  > I wanted to write a simple 3D game, maybe I could write most of it in C and use Forth for scripting
2022-07-03 10:57:37 <KipIngram   > I think the "C as the golden child" thing is totally true, though - I've decided that C has actually steered the development of processor technology for decades.
2022-07-03 10:57:51 <KipIngram   > CPU design has been about finding ways to run old legacy C code faster and faster.
2022-07-03 10:57:56 <dinklebink  > it did
2022-07-03 10:58:11 <dinklebink  > this is partially why I'm excited for RISC-V, it has the chance to burst the bubble
2022-07-03 10:58:19 <KipIngram   > A couple of months ago someone linked an article here, called "C is NOT a Low Level Language."
2022-07-03 10:58:27 <KipIngram   > The author laid it all out and I thought he did a great job.
2022-07-03 10:58:28 <dinklebink  > it doesn't have to be designed to handle Windows and old Windows app
2022-07-03 10:58:31 <KipIngram   > Really opened my eyes.
2022-07-03 10:58:44 <KipIngram   > I'd love to see that bubble burst.
2022-07-03 10:59:02 <KipIngram   > I sit around and wonder where we'd be right now if that focus on legacy software hadn't driven things.
2022-07-03 10:59:03 <lopata      > can you mix C and forth together ?
2022-07-03 10:59:15 <KipIngram   > You CAN, if things are set up for it.
2022-07-03 10:59:24 <dinklebink  > even better idea
2022-07-03 10:59:25 <MrMobius    > I would have to disagree about Forth not naturally being a slower language than C
2022-07-03 10:59:27 <dinklebink  > use forth and asm
2022-07-03 10:59:38 <KipIngram   > Forth can create a C call frame and then call a C routine.
2022-07-03 11:00:02 <KipIngram   > But any given Forth may or may not be set up to do that.
2022-07-03 11:00:35 <lopata      > there must have a Stack and a Heap
2022-07-03 11:00:37 <MrMobius    > in a highly optimized Forth like mecrisp where it's outputting optimized machine code like a C compiler, you're still 2-3x slower than the equivalent C. writing code for a stack machine introduces a bottleneck at the the top of the stack you dont have in C and that cant always be optimized away
2022-07-03 11:01:01 <KipIngram   > MrMobius: I think that depends a lot on the exact choice of words in your Forth.
2022-07-03 11:01:29 <KipIngram   > And yes, I do think typical Forths have such a bottleneck.
2022-07-03 11:01:32 <thrig       > probably why Leo Brodie wants lots of work before you start wording
2022-07-03 11:01:39 <KipIngram   > Of course, they also have implicit parameter passing, which helps.
2022-07-03 11:02:15 <lopata      > The register used by forth wouldn't Collision with a C running program ?
2022-07-03 11:02:19 <dinklebink  > Forth and ASM would provide a nice alternative for performant games, it'd just be a weird interface for most programmers to work with
2022-07-03 11:02:21 <MrMobius    > KipIngram, I dont think it does. I think you're looking at losing 80-90% of your performance on overhead in most forths which is approaching python levels. i get what youre saying about profiling and assembly though
2022-07-03 11:02:25 <dinklebink  > plus it'd limit platform portability
2022-07-03 11:02:26 <KipIngram   > lopata: Yeah, if you're going to call C, then anything that C requires has to be there.
2022-07-03 11:03:11 <KipIngram   > When you call a C function, you have to copy all of its parameters into a stack frame.  In Forth if you've coded well, they're "already there."
2022-07-03 11:03:28 <KipIngram   > How big a penalty that is depends on the situation.
2022-07-03 11:03:48 <lopata      > Yeah but the stack frame is such a complex thing that only C compiler know gow to build such
2022-07-03 11:03:52 <thrig       > or if you've inline static functions
2022-07-03 11:03:57 <MrMobius    > something like "SWAP 5 + SWAP" could be one assembly instruction instead of 20-30 like some forths so when I say "overhead" I mean the inevitable stack juggling that a C compiler doesnt suffer from
2022-07-03 11:03:58 <KipIngram   > And of course with all the C optimization that has gone on, bets are kind of off - they've found ways to step around a lot of those things.
2022-07-03 11:04:23 <MrMobius    > in addition to dispatch overhead
2022-07-03 11:04:25 <KipIngram   > But the fact that you NEED those SWAP calls means you've not done the best job arranging t hings on the stack.
2022-07-03 11:04:27 <lopata      > I dont think you can build a stack frame in forth
2022-07-03 11:04:37 <KipIngram   > It's the programmer's job to minimize the need for stack noodling.
2022-07-03 11:04:59 <MrMobius    > yes, it's the programmer's job but youll agree that not all DUP/SWAP/ROT noodling can be avoided
2022-07-03 11:05:16 <KipIngram   > lopata: you can put anything you want on the stack.
2022-07-03 11:05:25 <dinklebink  > Well, I was always looking for a language that was between C and ASM
2022-07-03 11:05:30 <KipIngram   > I've added words to my Forth such that I use very, VERY few of those.
2022-07-03 11:05:31 <lopata      > which stack?,
2022-07-03 11:05:34 <dinklebink  > and everyone said "it doesn't exist" and I didn't believe that
2022-07-03 11:05:40 <dinklebink  > it looks like Forth is kind of what I was looking for
2022-07-03 11:05:57 <lopata      > you mean use forth's stack for a C stack call?
2022-07-03 11:06:09 <KipIngram   > lopata: Yes, I see what you're saying.  You  might have to have a special group of words to make that "fit totally" into a C calling framework.
2022-07-03 11:06:25 <KipIngram   > Not just any plain vanilla Forth can do it - someone has to build into it the right capabilities.
2022-07-03 11:06:29 <thrig       > or you ASM and then call into C from that
2022-07-03 11:06:57 <KipIngram   > MrMobius: I'm talking about my "stack frame" mechanism.  It's eliminated stack noodling almost completely for me.
2022-07-03 11:07:19 <lopata      > Problem with stack : you can't go full recursive
2022-07-03 11:07:37 <KipIngram   > And I could make it even faster, if I'm willing to have an increased library of primitives.
2022-07-03 11:07:45 <MrMobius    > KipIngram, thats great. now if we can just get an optimizing compiler that supports that to compare performance
2022-07-03 11:08:15 <lopata      > try solve the fibonacci number, after 1000 recursive call stack, you overflow, and only get the 20 first values
2022-07-03 11:08:22 <KipIngram   > I actually agree with you that considering the tools available today C is likely to win, by about the factor you suggested.
2022-07-03 11:08:40 <dinklebink  > So, real question, if you mixed Forth and ASM, C would quickly lose its speed advantage?
2022-07-03 11:08:56 <KipIngram   > I'm just trying to speak in a "fully theoretical" way here.  And I'd actually be "cheating" by adding any mechanism at all to the Forth.
2022-07-03 11:09:01 <MrMobius    > ya Forth is fun for playing around with or if you can take the huge speed hit (ie probably doesnt matter unless youre on embedded)
2022-07-03 11:09:05 <KipIngram   > for "standard  Forth approaches" I totally agree with you.
2022-07-03 11:09:57 <KipIngram   > And different C programs would have different amounts of calling overhead.  I could contrive a C program that would lose a lot of performance setting up and tearing down its stack frames.
2022-07-03 11:10:00 <lopata      > Why not mixing Forth And Haskel ?
2022-07-03 11:10:16 <KipIngram   > But once again, it's the programmers job to write the C in a way that doesn't get bitten too much that way.
2022-07-03 11:10:25 <MrMobius    > dinklebink, no, it would still be dramatically slower but if the part in forth that is slow is not something that needs to be fast, the user will not notice the difference
2022-07-03 11:10:27 <KipIngram   > I don't know Haskel, lopata.  Sorry.
2022-07-03 11:11:25 <lopata      > haskell* functional oriented language
2022-07-03 11:11:29 <KipIngram   > MrMobius: I think the proper answer is to have the ability to code new primitives, profile your code, and write fast primitives for the performance gating bits of it.
2022-07-03 11:11:49 <KipIngram   > Then it really doesn't matter what language your useing - as you said, the user won't notice the speed difference.
2022-07-03 11:12:17 <KipIngram   > Once you have optimized machine code in the critical parts, everything is the same.
2022-07-03 11:13:37 <lopata      > B was created before C ait didn't have all the complexe C compiler optimization
2022-07-03 11:13:47 <MrMobius    > KipIngram, I get what youre saying but what I mean here is that even doing that, you will be several times slower than the equivalent C. there's just no way to organize Forth as we know it to match the speed
2022-07-03 11:14:16 <lopata      > Forth is meant to be like B, simple and raw, without the C gibberish
2022-07-03 11:14:50 <KipIngram   > Well, in that last remark I'm talking about the overall speed of an application, as perceived by a human user.  I think a lot depends on exactly how you define your test here.  And it also depends a lot on how well the Forth and the C have been written.
2022-07-03 11:15:17 <dinklebink  > you know I really love the way forth is laid out
2022-07-03 11:15:27 <dinklebink  > I love working in ASM bc it makes more sense to me than stuff like C
2022-07-03 11:15:34 <KipIngram   > If I have a 10-parameter C function that I'm calling over and over, the calling conventions are going to impose a lot of overhead, whereas the Forth can just re-use most of that stack frame throughout.
2022-07-03 11:15:46 <KipIngram   > But that would be stupid C.
2022-07-03 11:15:57 <MrMobius    > if you mean sometimes something faster doesnt appear to be faster because the user cant tell the difference between 1ms and 10ms then yes it could *appear* as fast but it *not* as fast
2022-07-03 11:16:02 <KipIngram   > Better to have another ONE parameter C call inside that bigger one.
2022-07-03 11:16:25 <MrMobius    > ya it depends on how well you write your Forth or C but lets just consider well written Forth vs well written C. there just isnt a way to do it where the speed will come close
2022-07-03 11:16:51 <lopata      > try step in all the calls frames for just one little printf("a") ? in C you get 800 asm lines just for it
2022-07-03 11:16:56 <dinklebink  > so you can do jank forth that'll be as performant?
2022-07-03 11:16:58 <lopata      > So C isn't faster than forth
2022-07-03 11:17:00 <dinklebink  > it's possible?
2022-07-03 11:17:00 <KipIngram   > I think that might depend on the exact primitives available.  I'm convinced that my stack frame t hing has sped up my code overall.
2022-07-03 11:17:19 <KipIngram   > Because I hardly even have dup or swap.  Once in a while.
2022-07-03 11:17:27 <dinklebink  > because remember, when it comes to game development, jank C is all over the place, especially in the early days, look at anything Carmack ever wrote
2022-07-03 11:17:35 <dinklebink  > you never write "good code" for performance related code
2022-07-03 11:17:37 <KipIngram   > But I've invented new primitives that minimize out the need for a lot of those.  And I don't even have ROT in my vocabulary.
2022-07-03 11:17:48 <KipIngram   > I just don't need it anymore.
2022-07-03 11:18:05 <KipIngram   > But I'm doing things most Forths can't do.
2022-07-03 11:18:17 <KipIngram   > On the other hand, I'm indirect threaded, and there's no way that's going to be as fast as C.
2022-07-03 11:18:39 <KipIngram   > I didn't really put in those new features to try to get "performance like C."
2022-07-03 11:18:41 <MrMobius    > KipIngram, im sure it does but without optimizations, youre losing tons of performance. maybe if you had your words and an optimizer that could take them into account youd do better than existing optimizing forths
2022-07-03 11:18:49 <KipIngram   > I put them in because it gives me more graceful looking source code.
2022-07-03 11:19:18 <KipIngram   > And easier to understand / debug source code.
2022-07-03 11:19:34 <KipIngram   > I "gave up" the performance contest the minute I chose indirect threading.
2022-07-03 11:19:50 <dinklebink  > MrMobius, so then, forth can be as fast, but you wouldn't be writing good code?
2022-07-03 11:20:27 <KipIngram   > Both languages have overhead.  Quality of the software can affect how much those overheads bite you.
2022-07-03 11:20:27 <MrMobius    > dinklebink, no, Forth by itself is much slower than C. the only way to get a similar experience for the user is to rewrite the parts that need to be fast from forth to assembly
2022-07-03 11:20:42 <dinklebink  > that's not a bad idea
2022-07-03 11:20:54 <KipIngram   > It's exactly the right idea.
2022-07-03 11:21:03 <KipIngram   > In any language, really.
2022-07-03 11:21:33 <KipIngram   > It's why you want a good profiler.
2022-07-03 11:21:44 <MrMobius    > I would say you should avoid assembly as much as you can which is why C compilers are so nice. otoh, i also use the Forth+asm combo for fun projects
2022-07-03 11:21:49 <KipIngram   > Sometimes you can "just see" where the high performance needs to be.
2022-07-03 11:21:53 <KipIngram   > Sometimes it's harder.
2022-07-03 11:22:08 <dinklebink  > MrMobius, I don't think portability matters for me for this project
2022-07-03 11:22:18 <dinklebink  > I'm looking to make something really "minimalist"
2022-07-03 11:22:23 <dinklebink  > and there's nothing more minimalist than ASM
2022-07-03 11:22:35 <KipIngram   > Typically the advantage Forth gives you is higher interactivity.
2022-07-03 11:22:48 <KipIngram   > You write little words that poke at your hardware, and then you can test them interactively.
2022-07-03 11:23:04 <KipIngram   > You aren't trapped in a "whole application" edit/compile/download/run cycle.
2022-07-03 11:23:21 <KipIngram   > Forth is good for "tinkering with things."
2022-07-03 11:23:22 <dinklebink  > "The team coded the game mostly in Forth[14] (unusual language, even for its time) with a few key routines written in x86 assembler. Forth was chosen since it is easier to use than assembler and more compact. This was important because the game had to fit into 128 KB of RAM. "
2022-07-03 11:23:38 <dinklebink  > something I always remember, when C is too bloated Forth gets used
2022-07-03 11:23:51 <KipIngram   > Yeah, Forth can be very compact.
2022-07-03 11:24:13 <KipIngram   > Byte code techniques can be even more so.
2022-07-03 11:24:21 <MrMobius    > dinklebink, it depends on your goal. if it's just for fun, you can use Forth or assembly or a combo. if it's serious, assembly is one of the worst things to maintain so I would stick to C
2022-07-03 11:24:50 <MrMobius    > ya Forth can save you space which is another advantage
2022-07-03 11:25:12 <MrMobius    > C is generally not bloated. youre trading space for speed
2022-07-03 11:26:07 <KipIngram   > Depends a lot on how much you use library routines and how they're implemented.  If calling one function can cause you to need a great big library linked in, that starts to be "bloated" by my definition.
2022-07-03 11:26:25 <KipIngram   > "Bloat" is stuff in your image that you're not actually using.
2022-07-03 11:26:48 <dinklebink  > isn't there other alternatives?
2022-07-03 11:26:57 <dinklebink  > something that's kinda like Forth but fast, still small?
2022-07-03 11:27:24 <dinklebink  > https://en.wikipedia.org/wiki/Brainfuck sort of like this but not a meme
2022-07-03 11:29:09 <thrig       > libc could be considered bloated and could be a nice attack surface
2022-07-03 11:29:59 <KipIngram   > I agree.
2022-07-03 11:31:42 <KipIngram   > dinklebink: Regardless of your vehicle, the strategy of identifying the performance critical parts of your application and coding them in assembly applies, and as far as I'm concerned that totally addresses the performance question.  If your next priority is size, then the *smallest* way to go is probably some kind of byte code interpreter.  Forth is probably next most compact.
2022-07-03 11:32:01 <thrig       > on the other hand writing your own printf-alike...
2022-07-03 11:32:13 <KipIngram   > I did a pretty good one in my last system.
2022-07-03 11:32:29 <KipIngram   > It used printf-style format strings, and they got processed by a byte-code interpreter.
2022-07-03 11:32:52 <KipIngram   > I had a word like TYPE, except it would recognize format strings and hand off to the bytee code engine.
2022-07-03 11:33:04 <KipIngram   > The engine "executed" the format strings, and each one consumed one argument from the stack.
2022-07-03 11:33:28 <KipIngram   > It wasn't a "full" printf by any means, but it captures the "90/10 situation" well enough for me.
2022-07-03 11:33:42 <thrig       > <# is pretty cool for a format generator
2022-07-03 11:33:51 <KipIngram   > Basically I just supported the ability to specify the radix used for the output, and the usual field width things.
2022-07-03 11:34:13 <KipIngram   > Yeah, the traditional method is pretty good.
2022-07-03 11:35:24 <MrMobius    > KipIngram, ya good point. getting a whole library linked in can really bloat things. i never use libc on embedded
2022-07-03 11:36:38 <MrMobius    > KipIngram, why would you need to write assembly in C for performance? on most architectures the compiler will do as well or better than you at that. rewriting part in assembly is usually a Forth thing
2022-07-03 11:41:48 <KipIngram   > You might not.  I'm just noting that that is always an available option.
2022-07-03 11:43:14 <KipIngram   > If we consider just "user's perception of application performance," as opposed to stopwatch measurements of every little bit of the code, then I'm just saying that that mechanism will let you get good performance pretty much regardless of language.
2022-07-03 11:43:49 <KipIngram   > And that in most situations you wouldn't need to do very much assembly - usually it's just a small part of the code that "counts" in that sense.
2022-07-03 11:44:04 <KipIngram   > And sure - if you've got a great optimizing C compiler you might not have to do ANY.
2022-07-03 11:44:06 <MrMobius    > right, if youre going for user perception then yes it will be the same if you can add enough assembly code. my point is that it will almost always appear as fast in C without having to write any assembly
2022-07-03 11:44:49 <MrMobius    > right
2022-07-03 11:44:50 <KipIngram   > I'm not really a C guy, but that is kind of how this conversation started - we talked about how C has been "the golden child" as far as optimization efforts have gone.
2022-07-03 11:45:17 <KipIngram   > And I noted how the desire to "run C fast" has even steered CPU design these last few decades.
2022-07-03 11:45:32 <KipIngram   > It's really been practically "all about C."
2022-07-03 11:45:41 <KipIngram   > Which already annoys me.  :-)
2022-07-03 11:45:43 <thrig       > Intel did try Itanium
2022-07-03 11:45:47 <MrMobius    > hehe
2022-07-03 11:45:55 <KipIngram   > Yes, and you had the Transputer guys too.
2022-07-03 11:46:05 <KipIngram   > But the "legacy momentum" was kind of just too much.
2022-07-03 11:46:46 <KipIngram   > I'm going to re-link that article that got linked a few months ago:
2022-07-03 11:46:48 <KipIngram   > https://medium.com/@garrytaylor_22287/c-is-not-a-low-level-language-5fca82d56b4
2022-07-03 11:46:54 <KipIngram   > That is absolutely worth reading.
2022-07-03 11:47:20 <KipIngram   > Oh, I'm not sure that's actually it.
2022-07-03 11:47:25 <KipIngram   > I was too hasty.
2022-07-03 11:47:36 <KipIngram   > Here:
2022-07-03 11:47:38 <KipIngram   > https://dl.acm.org/doi/pdf/10.1145/3209212
2022-07-03 11:48:28 <KipIngram   > The basic contention is that C was in fact low level - on the PDP11.
2022-07-03 11:48:55 <KipIngram   > But that since then CPUs have invested more and more logic in "propping up" that model, instead of deploying that logic as additional computing resources.
2022-07-03 11:49:29 <KipIngram   > So I totally agree with that "golden child" label - the deck has been stacked in tons of ways to favor C.
2022-07-03 11:52:12 <MrMobius    > ya it makes you wonder what a stack based processor with that many gates would look like
2022-07-03 11:53:17 <KipIngram   > Absolutely.
2022-07-03 12:02:24 <dinklebink  > well the target for this code will be RISC-V
2022-07-03 12:02:37 <dinklebink  > so maybe forth wouldn't hit performance too much
2022-07-03 12:02:45 <dinklebink  > I'm looking at languages and I like the look of lisp/scheme
2022-07-03 12:04:52 <thrig       > fingernail clippings in oatmeal, they've been called
2022-07-03 12:12:38 <dinklebink  > thrig, what?
2022-07-03 12:13:40 <thrig       > "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in."
2022-07-03 12:13:45 <KipIngram   > I think he's equating the parentheses to fingernail clippings.
2022-07-03 12:14:33 <KipIngram   > I'll confess that all those parentheses repelled me for a long time, but a year or two ago I spent some time thinking about how Lisp would be impemented internally and decided it could be quite simple (for a simple Lisp - not for a high tech optimized one).
2022-07-03 12:14:57 <KipIngram   > And that's one of the reasons I love Forth (how simple it is), so I decided that Lisp was perhaps somewhat interesting after all.
2022-07-03 12:15:02 <thrig       > well, you pretty much ignore them when lisping
2022-07-03 12:18:00 <KipIngram   > Yeah, I imagine good Lisps offer a lot of "management" to help with that.
2022-07-03 12:18:23 <MrMobius    > heh, i just imagine endless compiler errors until i strew enough parentheses around to get the compiler to shut up
2022-07-03 12:18:25 <thrig       > I write my lisp in vi, but I'm something of an oddball
2022-07-03 12:18:28 <KipIngram   > But when your a guy like me, with no exposure at all to Lisp, and you look at a block of code - it just looks like wall-to-wall parens.
2022-07-03 12:18:40 <KipIngram   > thrig: I try to use vim for everything.
2022-07-03 12:18:53 <KipIngram   > Well, everything editing.
2022-07-03 12:18:57 <thrig       > I didn't say vim
2022-07-03 12:19:03 <KipIngram   > No, you didn't.
2022-07-03 12:19:25 <KipIngram   > But I used to use emacs, and then switched to vim, so I never stopped off at vi.
2022-07-03 12:19:43 <dinklebink  > I'm terrible with syntax
2022-07-03 12:19:49 <dinklebink  > languages like Forth, Brainfuck, Lisp
2022-07-03 12:19:54 <dinklebink  > they make more sense to me than C
2022-07-03 12:19:55 <thrig       > yeah, emacs was tearing up my tendons so I dropped it like 20 years ago
2022-07-03 12:20:25 <dinklebink  > I gotta mention, I started using a lot of that silly suckless stuff the unix people talk about, dwm, dmenu, qutebrowser (web browser with vim-like bindings)
2022-07-03 12:20:30 <KipIngram   > I just decided that I was surrounded by vim users, so in a VERY RARE instance (for me) of conformity, I joined them.
2022-07-03 12:20:35 <dinklebink  > I really like using vi-style bindings for a lot of programs
2022-07-03 12:20:37 <KipIngram   > Just so I could adopt techniques from them.
2022-07-03 12:20:46 <thrig       > mupdf is pretty vi-like
2022-07-03 12:20:48 <KipIngram   > Plus it just felt like vim got more development attention out in the world.
2022-07-03 12:21:02 <dinklebink  > thrig, yeah, stuff like that, if I could get a vi-style file browser I'd be in business
2022-07-03 12:21:30 <thrig       > oh jk do the right things and there's mark and so forth I'm good
2022-07-03 12:30:30 <dinklebink  > https://github.com/cesarblum/sectorforth
2022-07-03 12:30:36 <dinklebink  > at this point, why not just use ASM?
2022-07-03 12:48:16 <dinklebink  > KipIngram, isn't it possible that by its nature, a CPU designed for performant forth could be simpler than a CPU designed for performant C?
2022-07-03 12:56:43 <remexre     > depends how performant "performant" is; if you're doing something that competes with a modern PC or smartphone CPU, IDK what all gets easier
2022-07-03 13:00:02 <KipIngram   > dinklebink: I think that's a fairly complex question.
2022-07-03 13:00:12 <KipIngram   > CPUs are NOT simple these days.
2022-07-03 13:00:23 <KipIngram   > All the cache management, out of order execution, etc. etc.
2022-07-03 13:00:28 <KipIngram   > Read that article - it's good.
2022-07-03 13:00:44 <KipIngram   > A Forth CPU could *potentially* be VERY simple.
2022-07-03 13:07:07 <KipIngram   > An interesting 16-bit design uses the MSB of each 16-bit cell to indicate whether that cell contains opcodes or an address.  If it's opcodes, then the remaining 15 bits contain three packed opcodes; if it's an address, it's the address of a Forth word to thread to.  That way you get the "compactness" of five bit instructions, and Forth.
2022-07-03 13:07:34 <KipIngram   > For a 32-bit design you can have six five bit opcodes packed in there, and more options for interpretation, since the remaining two bits cover four cases instead of just two.
2022-07-03 13:09:30 <KipIngram   > The hardware to handle those cases is pretty simple.
2022-07-03 13:10:58 <KipIngram   > It's easy for the hardware to cache the most recent opcodes, so you can do micro-loops on those.
2022-07-03 13:12:18 <KipIngram   > I found that a Harvard architecture worked nicely - a fetch unit reads the program content out of instruction RAM, handles the threading, and streams the discovered opcodes to an execute unit, that handles them.
2022-07-03 13:12:50 <KipIngram   > As usual with such a system conditional jumps threaten to stall your pipeline, so you can decide how far backward you want to bed over trying to mitigate that.
2022-07-03 13:12:57 <KipIngram   > s/bed/bend/
2022-07-03 13:13:26 <dinklebink  > harvard architecture worked nicely with forth?
2022-07-03 13:13:35 <dinklebink  > harvard architecture is like, the simplest option isn't it
2022-07-03 13:13:54 <KipIngram   > But since you're fetching three to six opcodes whenever you fetch them, it's easy enough for the fetch unit to get out ahead of the execute unit, which mitigates the call overhead of highly factored code.
2022-07-03 13:14:20 <KipIngram   > I thought so, dinklebink.  Of course, getting the instruction ram set up in the first place represents a "detour" from mainline operation.
2022-07-03 13:14:24 <KipIngram   > That adds complexity.
2022-07-03 13:14:34 <KipIngram   > But for EXECUTING the program, it seemed to work well.
2022-07-03 13:14:51 <KipIngram   > I played with it a good bit on paper, with a Spartan 6 FPGA target in mind, but never actually built it.
2022-07-03 13:15:23 <KipIngram   > I felt like I could make it with just two layers of LUTs between clock edges, so it looked like it could have a fairly fast clock.
2022-07-03 13:16:03 <KipIngram   > Providing the ability for the execute unit to read and write instruction RAM, though, was a kind of ugly hack.
2022-07-03 13:16:55 <KipIngram   > That relied on having some chunk of executable code already in the pipeline - then it would turn off fetching, modify instruction ram, and turn fetching back on.
2022-07-03 13:17:14 <KipIngram   > There had to be enough pipelined opcodes to do that, so you're talking about a somewhat deep fifo between fetch and execute.
2022-07-03 13:17:46 <KipIngram   > If you turned off fetching and then exhausted the already fetched opcodes, you'd be hung.
2022-07-03 13:19:20 <remexre     > hm, could you do something overcomplicated with having a separate "memcpy controller" that you use to bulk copy between (and within) them?
2022-07-03 13:19:29 <KipIngram   > You could, yes.
2022-07-03 13:19:47 <KipIngram   > It also may have been the Spartan 6 architecture that encouraged a Harvard approach - it has those dual ported block RAMs.
2022-07-03 13:20:22 <KipIngram   > Hmmm.  Maybe that solves the instruction RAM modify problem.
2022-07-03 13:20:34 <KipIngram   > Maybe there never was a problem.  It's the same RAM.
2022-07-03 13:21:01 <KipIngram   > Or maybe I'm forgetting something - that seems like something I would have noticed at the time, so maybe it doesn't work for some forgotten reason.
2022-07-03 13:21:03 <remexre     > I mean, self-modifying code + a pipeline are always tricky, I thought
2022-07-03 13:21:10 <KipIngram   > Yeah.
2022-07-03 13:21:24 <KipIngram   > I really optimized it for execution of an existing program.
2022-07-03 13:21:40 <KipIngram   > And five bit opcodes is "barely enough."
2022-07-03 13:22:09 <KipIngram   > But Chuck had a five bit opcode design; I really stole the "three packed opcodes" idea from one of his designs.
2022-07-03 13:22:19 <KipIngram   > F21?
2022-07-03 13:22:33 <remexre     > that sounds familiar, yeah
2022-07-03 13:23:07 <KipIngram   > When I thought about 32-bit implementation, it was awfully tempting to have five 6-bit opcodes instead of six 5's.
2022-07-03 13:23:18 <KipIngram   > Because 64 is plenty.
2022-07-03 13:23:51 <KipIngram   > And iirc the Spartan 6 had six-input LUTs, so that fit nicely too.
2022-07-03 14:45:21 <dinklebink  > what are good resources for learning forth?
2022-07-03 14:46:14 <thrig       > Leo Brodie books
2022-07-03 15:00:44 <dinklebink  > Since Forth mixes and interpreter with a compiler, couldn't it be used as a very minimalist OS?
2022-07-03 15:02:18 <dinklebink  > sort of like how CP/M / DOS used to be just loaders for various programs with a common file system?
2022-07-03 15:02:53 <imode       > yeah.
2022-07-03 15:07:26 <dinklebink  > this is exactly what I've always wanted from programming
2022-07-03 15:07:46 <dinklebink  > something high level that reminded me of all the stuff I liked about ASM and nand2tetris
2022-07-03 15:07:49 <dinklebink  > why isn't this more popular?
2022-07-03 15:07:50 <dinklebink  > ???
2022-07-03 15:08:12 <imode       > largely because forth is relatively obtuse and lower to the ground than other languages. with minor pokes at historical baggage.
2022-07-03 15:09:10 <imode       > you also have the "smalltalk" problem, and code re-use/distribution isn't that much of a priority.
2022-07-03 15:09:32 <dinklebink  > imode, but forth/asm is a complete alternative to the entire way we do programming today, no?
2022-07-03 15:09:56 <imode       > for toy examples and small projects, sure.
2022-07-03 15:12:43 <dinklebink  > imode, but I mean, it fits the suckless philosophy, I guess
2022-07-03 15:12:59 <imode       > ah, that useless thing.
2022-07-03 15:13:21 <imode       > that isn't something to be proud of.
2022-07-03 15:13:36 <dinklebink  > not useless to me
2022-07-03 15:13:43 <dinklebink  > I like suckless software, it works well for me
2022-07-03 15:13:45 <imode       > no, just useless for programming at large.
2022-07-03 15:14:08 <dinklebink  > I'm trying to figure out how to make a RISC-V SBC into something functional for the vast majority of what I want to do
2022-07-03 15:14:30 <dinklebink  > and suckless helps, small linux distros, dwm, dmenu, qutebrowser
2022-07-03 15:14:32 <imode       > I enjoy Forth. but simple is hard. being close to the metal is hard. "the way we do programming today" is not low-level, it's very high-level, with lots of abstractions away from the metal.
2022-07-03 15:14:47 <dinklebink  > yeah that's why it sucks
2022-07-03 15:15:00 <imode       > sure. but it does make money. and we are not the only users of computers.
2022-07-03 15:15:11 <dinklebink  > making money shouldn't be a goal of software
2022-07-03 15:15:29 <imode       > it was the goal of building consumer computing hardware.
2022-07-03 15:15:42 <imode       > therefore, by transitivity, that's the goal of software, which is to make that hardware useful.
2022-07-03 15:16:01 <dinklebink  > consumer software/hardware doesn't have to use giant libraries on top of libraries to be user friendly
2022-07-03 15:16:20 <imode       > and yet I'm not going to give my grandmother a forth prompt.
2022-07-03 15:16:23 <dinklebink  > there's no reason why a sensible TUI couldn't be just as functional as some Qt thing with giant buttons
2022-07-03 15:16:31 <dinklebink  > or even basic GUIs
2022-07-03 15:16:42 <imode       > heh, there's several reasons, which is why we're here today.
2022-07-03 15:16:56 <dinklebink  > those reasons are cash
2022-07-03 15:17:06 <imode       > which is given to you by consumers.
2022-07-03 15:17:10 <imode       > which need a usable product.
2022-07-03 15:17:12 <imode       > so.
2022-07-03 15:17:17 <imode       > yeah, cash.
2022-07-03 15:18:17 <dinklebink  > but you don't need giant DEs and firefox for something to be usable
2022-07-03 15:18:22 <imode       > people enjoy usable, readable computer interfaces. it's very difficult to do that with text input, because you suffer from the text adventure problem: where do you obtain the knowledge of what to type. it's easy to just click around for a bit and discover in a "traditional UI".
2022-07-03 15:18:34 <imode       > because there's a way of exploring the decision tree.
2022-07-03 15:18:38 <dinklebink  > what do you think TUI stands for
2022-07-03 15:18:43 <imode       > text user interface.
2022-07-03 15:18:54 <dinklebink  > TUI =/= CLI
2022-07-03 15:19:05 <imode       > the same applies for a terminal user interface. I don't want block characters limiting what I can draw lmao.
2022-07-03 15:20:18 <dinklebink  > but again, just bc it's a GUI doesn't mean it needs qt on top of x on top of debian etc. etc.
2022-07-03 15:21:36 <imode       > you're right on all accounts. and yet there's a reason why a complete forth system hasn't been built.
2022-07-03 15:21:47 <imode       > well, a couple of reasons.
2022-07-03 15:22:05 <imode       > one of which is the obvious historical baggage, another is the fact that.. yeah, forth is obtuse.
2022-07-03 15:22:15 <dinklebink  > I get it man, normies
2022-07-03 15:22:29 <imode       > far be it, even heavy engineering types don't wanna use it.
2022-07-03 15:22:31 <dinklebink  > but that shouldn't direct the entire IT industry
2022-07-03 15:22:37 <imode       > also, really, "normies".
2022-07-03 15:22:42 <imode       > forth is niche lmao.
2022-07-03 15:22:57 <dinklebink  > suckless is idiotic and yet completely necessary
2022-07-03 15:23:14 <imode       > when someone builds a competitive forth environment, let me know.
2022-07-03 15:23:19 <imode       > it won't happen. god knows I'm trying.
2022-07-03 15:23:19 <dinklebink  > and I've often noticed that until presented with an alternative, people will assume things are the way they are bc the alternative wouldn't be functional
2022-07-03 15:23:35 <dinklebink  > but I didn't think I'd be able to use FreeBSD/dwm/dmenu/qutebrowser until I did and realized "this is easy"
2022-07-03 15:23:40 <dinklebink  > I'm not even much of a programmer
2022-07-03 15:23:55 <imode       > far be it from me to discourage exposure to alternatives.
2022-07-03 15:24:06 <imode       > my entire family runs on linux.
2022-07-03 15:24:07 <dinklebink  > a lot of the suckless diehards (like me) are just people who made the switch and decided it wasn't that hard
2022-07-03 15:24:12 <dinklebink  > people used to use DOS just fine
2022-07-03 15:24:17 <dinklebink  > imode, that's great tbh
2022-07-03 15:24:30 <imode       > mostly on GNOME, but that's a sidebar.
2022-07-03 15:24:51 <imode       > they wouldn't know their ass from their head about installing it, though.
2022-07-03 15:24:56 <imode       > or managing it, or updating it.
2022-07-03 15:25:20 <dinklebink  > but there's linux distros that do that so you don't have to aren't there?
2022-07-03 15:25:22 <dinklebink  > Ubuntu and stuff
2022-07-03 15:25:32 <dinklebink  > I don't know personally bc I just use stuff like Alpine or FreeBSD
2022-07-03 15:25:32 <imode       > not really, you still have to get in the hairy weeds every so often.
2022-07-03 15:25:40 <imode       > there's no shortage of support requests for that.
2022-07-03 15:25:47 <dinklebink  > what about pop os?
2022-07-03 15:25:50 <dinklebink  > or that shit steam uses
2022-07-03 15:26:08 <imode       > I've got a steam deck and yeah they have wrapped that thing up so tight it can barely move on you. vended updates, etc.
2022-07-03 15:26:15 <imode       > not sure about pop, but I've heard good things.
2022-07-03 15:26:18 <dinklebink  > oh nice
2022-07-03 15:26:24 <dinklebink  > I'm a bit of a luddite
2022-07-03 15:26:28 <imode       > you don't even know it's running arch.
2022-07-03 15:26:31 <dinklebink  > and Forth seems nice from that perspective
2022-07-03 15:26:39 <imode       > well, it's because it's "simple".
2022-07-03 15:26:49 <imode       > and that's fine. but a lot of things that are simple are hard.
2022-07-03 15:27:04 <imode       > a lot of processor architectures are "simple".
2022-07-03 15:27:05 <dinklebink  > that's fine, I've done a bit of nand2tetris, and some ASM
2022-07-03 15:27:11 <dinklebink  > for me, Forth is exactly what I've been looking for
2022-07-03 15:27:29 <dinklebink  > a way of using portable code that doesn't completely remove me from working close to the metal
2022-07-03 15:27:30 <imode       > try building a larger application with Forth and you'll see where the cracks are. it's great for single-user systems.
2022-07-03 15:27:43 <imode       > forth code is anything but portable.
2022-07-03 15:27:46 <dinklebink  > but the question is
2022-07-03 15:27:52 <imode       > because there's no "one forth".
2022-07-03 15:27:53 <dinklebink  > why would you want a larger program?
2022-07-03 15:28:05 <imode       > because complexity doesn't have fine grained boundaries.
2022-07-03 15:28:21 <imode       > and the average user would like to not stitch together a pipeline to do a trivial task.
2022-07-03 15:28:23 <remexre     > e.g. let's say I want to be able to read and write text written in either English or Arabic
2022-07-03 15:28:45 <dinklebink  > the average user should never touch anything I write tbh
2022-07-03 15:28:48 <remexre     > (and linking to a huge C library to do font rendering is out of bounds)
2022-07-03 15:29:46 <imode       > yeah, font rendering is one of those unseen pillars of computing, like a sewage system.
2022-07-03 15:29:52 <imode       > do that in forth.
2022-07-03 15:30:04 <dinklebink  > that's assuming I want my PC to handle Arabic
2022-07-03 15:30:10 <imode       > okay do english.
2022-07-03 15:30:34 <imode       > write me a document viewer.
2022-07-03 15:32:10 <dinklebink  > sure, I'll write it to read AsciiDoc
2022-07-03 15:33:18 <imode       > you're learning that "complex standards and simple languages don't mesh". there's a reason why people are in awe of the fact that Rollercoaster Tycoon was written in assembly.
2022-07-03 15:33:34 <dinklebink  > I'm not learning anything
2022-07-03 15:33:40 <dinklebink  > I understand what a complex standard is
2022-07-03 15:33:45 <imode       > write me a PDF reader, then.
2022-07-03 15:33:48 <dinklebink  > I also understand that I don't care for them
2022-07-03 15:33:54 <imode       > you don't care about reading PDFs?
2022-07-03 15:33:58 <dinklebink  > imode, I've got a better idea, don't use PDFs
2022-07-03 15:34:02 <MrMobius    > heh
2022-07-03 15:34:06 <imode       > sure, let me tell the rest of the world that.
2022-07-03 15:34:14 <dinklebink  > I'll tell them first
2022-07-03 15:34:19 <dinklebink  > they can throw the eggs at me instead
2022-07-03 15:34:21 <imode       > I'm sure they'll be very receptive.
2022-07-03 15:35:01 <imode       > if you want to rewrite the computing stack from scratch, go for it. but complexity is inherent in the things we want to do.
2022-07-03 15:35:21 <imode       > I _want_ complex typesetting, I _want_ real-time graphics, I want a reasonable UI.
2022-07-03 15:36:20 <imode       > overcoming that complexity plateau is difficult unless you spend literal decades thinking about it.
2022-07-03 15:36:31 <MrMobius    > imode, thats completely unreasonable. if you want an MRI, your doctor should be able to view it on a text terminal
2022-07-03 15:36:48 <imode       > MrMobius: "this glyph here represents a tumor".
2022-07-03 15:37:03 <imode       > dwarf fortress DICOM extension when.
2022-07-03 15:37:11 <imode       > I wanna be able to import my brain.
2022-07-03 16:03:00 <dinklebink  > I don't want any of those things imode
2022-07-03 16:03:15 <imode       > then go use an IBM XT, my dude.
2022-07-03 16:03:26 <imode       > go compete with WordStar.
2022-07-03 16:04:31 <dinklebink  > I would but I try to avoid non-free hardware
2022-07-03 16:04:40 <imode       > all of your hardware is non-free.
2022-07-03 16:04:45 <imode       > you had to pay for it and someone owns the IP for it.
2022-07-03 16:04:55 <dinklebink  > not once I buy that RISC-V SBC that was announced yesterday
2022-07-03 16:05:23 <imode       > that doesn't mean you're not using non-free hardware...?
2022-07-03 16:05:35 <imode       > a company is making the SBC.
2022-07-03 16:05:38 <remexre     > (how) does it do video output? (which one was it)
2022-07-03 16:05:55 <imode       > a company owns the IP for the board.
2022-07-03 16:05:57 <dinklebink  > imode, a sbc can be free?
2022-07-03 16:06:05 <imode       > it.. can't.
2022-07-03 16:06:25 <imode       > unless they explicitly declare their IP to be free and open source.
2022-07-03 16:06:25 <dinklebink  > it can
2022-07-03 16:06:28 <dinklebink  > right
2022-07-03 16:06:36 <imode       > and grant the appropriate licenses.
2022-07-03 16:06:37 <imode       > but.
2022-07-03 16:06:45 <imode       > I don't think that's the case.
2022-07-03 16:06:48 <dinklebink  > and there are companies that do this
2022-07-03 16:06:56 <imode       > which RISC-V board are you talking about.
2022-07-03 16:10:22 <dinklebink  > imode, https://www.pine64.org/2022/06/28/june-update-who-likes-risc-v/
2022-07-03 16:10:55 <imode       > that's not free.
2022-07-03 16:12:28 <dinklebink  > I might be wrong pine64 might not be a company that does open source designs
2022-07-03 16:12:29 <dinklebink  > https://en.wikipedia.org/wiki/BeagleBoard
2022-07-03 16:12:32 <dinklebink  > BeagleV should be though
2022-07-03 16:12:51 <remexre     > sadly most of the hw on pine's stuff is closed-source, ya
2022-07-03 16:12:55 <imode       > beagle doesn't either..
2022-07-03 16:13:00 <remexre     > some of it is even no-docs-except-with-nda
2022-07-03 16:13:35 <imode       > beagle isn't free.
2022-07-03 16:15:16 <dinklebink  > I'm not sure what your definition of free is
2022-07-03 16:15:24 <imode       > what's yours.
2022-07-03 16:15:53 <imode       > 'cuz everything you've shown has nonfree blobs and nonfree chips, in the spirit of FOS(H|S).
2022-07-03 16:16:07 <dinklebink  > open design even if it needs some closed components, if another company can sell a clone of that computer with no legal issues, just off the shelf parts, that's open
2022-07-03 16:16:18 <imode       > hahahahahahaha okay.
2022-07-03 16:16:28 <imode       > good luck making a beaglebone board.
2022-07-03 16:16:47 <remexre     > yeah, wait, you can't just buy "raw" SoCs on amazon
2022-07-03 16:16:55 <imode       > not even through digikey.
2022-07-03 16:17:05 <imode       > or similar suppliers.
2022-07-03 16:18:07 <dinklebink  > oh well, we'll get as close as we can
2022-07-03 16:18:19 <dinklebink  > that's disappointing to hear about Pine though
2022-07-03 16:18:40 <remexre     > as far as i can tell they _are_ doing the best they can
2022-07-03 16:18:51 <imode       > there's no such thing as free hardware yet.
2022-07-03 16:18:54 <remexre     > but they don't really have any leverage against e.g. ARM to open up their designs
2022-07-03 16:18:56 <imode       > you can damn well try.
2022-07-03 16:19:04 <imode       > but unless you can socialize a foundry that's not happening.
2022-07-03 16:19:39 <remexre     > have you seen the Precursor, semi-relatedly?
2022-07-03 16:19:45 <dinklebink  > I don't think so
2022-07-03 16:19:50 <imode       > I haven't.
2022-07-03 16:19:57 <dinklebink  > I was just looking at this MNT Reform Pocket
2022-07-03 16:20:00 <remexre     > https://www.bunniestudios.com/blog/?p=5921
2022-07-03 16:20:02 <dinklebink  > which is a step in the right direction
2022-07-03 16:20:17 <dinklebink  > https://mntre.com/media/reform_md/2022-06-20-introducing-mnt-pocket-reform.html
2022-07-03 16:20:19 <imode       > helllloooo, what is this.
2022-07-03 16:20:42 <remexre     > https://www.crowdsupply.com/sutajio-kosagi/precursor has more info
2022-07-03 16:21:14 <dinklebink  > imode, if we don't push as hard as we can, we would've never gotten stuff like this
2022-07-03 16:21:27 <dinklebink  > remexre, why would I use this over something like pinephone? just simpler, more secure, not a smartphone?
2022-07-03 16:21:34 <imode       > oh god, rust-based apps..
2022-07-03 16:21:47 <dinklebink  > eww rust
2022-07-03 16:21:48 <remexre     > dinklebink: it's FPGA-based, and you bring your own CPU to it
2022-07-03 16:21:49 <imode       > good that they're using FPGAs. please keep using FPGAs.
2022-07-03 16:21:53 <dinklebink  > remexre, sexy
2022-07-03 16:22:00 <dinklebink  > I have a de-10 nano sitting behind me
2022-07-03 16:22:03 <dinklebink  > not sure what to do with it
2022-07-03 16:22:08 <imode       > this looks sexy.
2022-07-03 16:22:33 <dinklebink  > but does the fpga depend on some other thing to load stuff?
2022-07-03 16:22:41 <dinklebink  > I know that's usually the bottleneck for FPGAs, but this is great
2022-07-03 16:22:43 <imode       > it's a spartan FPGA, so.
2022-07-03 16:22:47 <imode       > not a full FOSS toolchain.
2022-07-03 16:23:09 <imode       > that looks sleek as shit though, I want one.
2022-07-03 16:23:56 <dinklebink  > that MNT Pocket Reform I posted can take an FPGA too
2022-07-03 16:24:01 <remexre     > yeah, I would get one but my "gadgets-to-do-stuff-with pile" is getting too tall...
2022-07-03 16:24:29 <remexre     > my current forth's end goal is to be run instead of linux on a pinephone lmao
2022-07-03 16:24:31 <imode       > I actually need a device to test out a new processor design.
2022-07-03 16:24:45 <imode       > this would be killer.
2022-07-03 16:24:58 <eris[m]     > imode: imode: they have a lot of justification here
2022-07-03 16:25:03 <dinklebink  > remexre, I'm in love
2022-07-03 16:25:08 <dinklebink  > I'm about to order a pinephone
2022-07-03 16:25:18 <eris[m]     > the spartan is the one that they can confirm hardware wise doesnt have any fuckery
2022-07-03 16:25:18 <imode       > is that an e-ink display?
2022-07-03 16:25:27 <eris[m]     > no
2022-07-03 16:25:32 <imode       > just monochrome.
2022-07-03 16:25:36 <imode       > I'll take it. it's hella cool.
2022-07-03 16:25:47 <remexre     > dinklebink: hah, any chance you have a burning desire to write a modem or touchscreen driver?
2022-07-03 16:26:00 <imode       > $590?!
2022-07-03 16:26:04 <imode       > holy shit.
2022-07-03 16:28:27 <dinklebink  > >590
2022-07-03 16:28:28 <dinklebink  > yeah no
2022-07-03 16:28:33 <dinklebink  > I'll wait a few years
2022-07-03 16:29:00 <dinklebink  > remexre, here's the thing, we can shit on the suckless people, but they make stuff like this https://sxmo.org/
2022-07-03 16:29:16 <remexre     > this message sent from st /shrug
2022-07-03 16:29:25 <remexre     > (not ii tho)
2022-07-03 16:29:28 <dinklebink  > oh I meant imode lmao
2022-07-03 16:29:38 <remexre     > my main gripe with the st people on a technical level is that they pretend their complexity doesn't exist
2022-07-03 16:29:46 <remexre     > instead of acknowledging that they moved it all to X
2022-07-03 16:29:50 <imode       > they also are closeted nazis.
2022-07-03 16:30:08 <remexre     > yeah, I had to go back and add "on a technical level" :)
2022-07-03 16:30:18 <imode       > heh.
2022-07-03 16:30:20 <dinklebink  > but the thing is
2022-07-03 16:30:21 <dinklebink  > x is there
2022-07-03 16:30:39 <dinklebink  > even if I install something like GNOME Terminal, X is still there
2022-07-03 16:30:50 <dinklebink  > let something that's going to be there anyway handle the complexity
2022-07-03 16:30:51 <remexre     > now this message was typed from kmscon on my other machine :P
2022-07-03 16:30:54 <dinklebink  > it removes dependencies
2022-07-03 16:30:58 <imode       > why not go all the way.
2022-07-03 16:31:02 <imode       > use wmutils.
2022-07-03 16:31:10 <imode       > literal shellscripts for X.
2022-07-03 16:31:17 <dinklebink  > I might
2022-07-03 16:31:41 <dinklebink  > I don't really tile windows much, I have one workspace with a fullscreen browser and a second workspace with a fullscreen terminal, and then terminal utilities and stuff
2022-07-03 16:32:26 <eris[m]     > <imode> "$590?!" <- two fpgas
2022-07-03 16:32:35 <imode       > yeah.
2022-07-03 16:32:40 <imode       > sexy.
2022-07-03 16:32:42 <imode       > I want one.
2022-07-03 16:33:20 <dinklebink  > I think I'm gonna order a pinephone
2022-07-03 16:46:39 <KipIngram   > Oh... pinephone looks nifty.
2022-07-03 17:06:24 <dinklebink  > coupled with that SXMO thing I linked it works pretty well and fast
2022-07-03 17:13:46 <KipIngram   > I would *love* to do a Linux phone.  I'd feel like I'd cut my last ties to "the establishment."
2022-07-03 17:20:59 <KipIngram   > I hope this is like any Linux system that deserves the name, and I can easily become root?
2022-07-03 17:21:10 <KipIngram   > Without having to go through some funky "jailbreak" procedure?
2022-07-03 17:21:14 <remexre     > pinephone? it's bring-your-own-distro
2022-07-03 17:21:23 <KipIngram   > Oh.
2022-07-03 17:21:27 <KipIngram   > ANY Linux???
2022-07-03 17:21:40 <KipIngram   > How does it offer up the phone service?
2022-07-03 17:21:58 <remexre     > iiuc, modemmanager handles everything but the audio
2022-07-03 17:22:14 <remexre     > and "normal things" (alsa, pulse, etc) can get audio to/from the modem
2022-07-03 17:22:20 <imode       > really now.
2022-07-03 17:22:40 <imode       > so I can dial a number via modemmanager and then feed the audio from a headset or something, there has to be an application tying it together.
2022-07-03 17:23:07 <KipIngram   > Ok, so it's like having an executable that runs the radio, and that just plugs into the OS services?
2022-07-03 17:23:07 <remexre     > I've only tried the gnome-based gui, but the keyboard was like, unusably laggy
2022-07-03 17:23:09 <eris[m]     > KipIngram: not any linux, pine has a few kernel modules not upstreamed yet afaik
2022-07-03 17:23:31 <KipIngram   > Ok.  But still - feels like "how it should be."
2022-07-03 17:23:42 <KipIngram   > How it should have been from the very beginning.
2022-07-03 17:24:12 <eris[m]     > yes
2022-07-03 17:24:33 <eris[m]     > essentially there are pinephone distros which're adaptations of normal ones
2022-07-03 17:24:43 <eris[m]     > ie. carries all the phone specific stuff
2022-07-03 17:24:56 <remexre     > KipIngram: https://xnux.eu/devices/feature/modem-pp.html
2022-07-03 17:25:20 <KipIngram   > These prices are eminently reasonable.
2022-07-03 17:25:48 <KipIngram   > I may have to do this.  Reasonable portability across providers?
2022-07-03 17:38:43 <dinklebink  > KipIngram, pretty sure it's the same as any unlocked phone
2022-07-03 20:42:40 <dinklebink  > how can I get a job working in Forth
2022-07-03 20:43:16 <imode       > build a forth or use a forth at a current job.
2022-07-03 20:43:28 <dinklebink  > neat
2022-07-03 20:43:52 <imode       > I can probably count the number of professional forth programmers on one hand.
2022-07-03 20:50:08 <dinklebink  > Thinking Forth and Starting Forth
2022-07-03 20:50:10 <dinklebink  > that's how I do this right?
2022-07-03 20:52:55 <thrig       > alphabetically, probably
2022-07-03 20:53:28 <thrig       > SF also needs a few adjustments for a not-16-bit-cell-size forth and other minor issues
2022-07-03 21:03:49 <dinklebink  > so I start with Starting?
2022-07-03 21:04:30 <thrig       > it will teach more forth if you don't know that. the other is more meta
2022-07-03 21:04:52 <dinklebink  > I'm lost
2022-07-03 21:04:54 <dinklebink  > I just want to learn Forth
2022-07-03 21:05:18 <MrMobius    > ya Starting Forth assumes you dont know much of anything about Forth
2022-07-03 21:19:42 <dinklebink  > so what Forth do I use for this book?
2022-07-03 21:38:05 <dinklebink  > thrig
2022-07-03 22:09:21 <thrig       > I used pforth, which requires some code changes in a few spots
2022-07-03 22:10:25 <KipIngram   > Thinking Forth is a great book.
2022-07-03 22:11:31 <KipIngram   > It's one of my two favorites - the other one is "Forth Fundamentals, Volume 1" by McCabe.  Totally different books - TF is really about programming in general and how to write good Forth code; FF is about the nuts and bolts of a typical Forth implementation.  The "under the hood" stuff.
2022-07-03 22:11:39 <KipIngram   > How it *works*.
2022-07-03 22:12:20 <imode       > Threaded Interpretive Languages is also a classic, but you'll need a Z80, it's very much coupled to it.
2022-07-03 22:12:42 <thrig       > z80 interp should be easy to find?
2022-07-03 22:33:17 <KipIngram   > I think a lot of the ideas in Thinking Forth are applicable to any language, though of course it's Forth focused.
2022-07-03 22:33:34 <KipIngram   > It's really kind of a book on "intelligent software design."
2022-07-03 22:35:10 <KipIngram   > Forth is a little different from a lot of languages, in that it it always looks the same, whatever level you're at.  Whereas in, say, C, a function call looks quite different from an expression.
2022-07-03 22:35:35 <KipIngram   > Forth is "seamless" in a really nice way.