2026-02-28 11:50:27 <veltas      > tulushev: Yep portability and also doing more accurate calculations e.g. doing a big average you'd be safer using a double integer as an intermediate
2026-02-28 11:51:18 <veltas      > Someone challenged me to write linear regression in Forth so I wrote a program that worked on my ZX Spectrum as well as gforth, so on gforth that was using 128-bit integers in places
2026-02-28 11:51:45 <veltas      > But the big advantage was that it would use 32-bit intermediates on the ZX Spectrum, so be able to perform the calculation accurately
2026-02-28 11:53:06 <veltas      > It's useful on 32-bit platforms which are everywhere, 64-bit is a safe size for most things as KipIngram said so if you support 32-bit embedded chips it's good to have mixed precision available for 64-bit intermediates
2026-02-28 11:59:23 <cleobuline  > forthBot:    1 127 <<  .
2026-02-28 11:59:23 <forthBot    > 170141183460469231731687303715884105728
2026-02-28 12:00:26 <cleobuline  > forthBot:  170141183460469231731687303715884105728 NUM-TO-BIN .
2026-02-28 12:00:27 <forthBot    > 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2026-02-28 12:00:27 <forthBot    > Error: Stack underflow
2026-02-28 12:00:27 <forthBot    > 0
2026-02-28 12:00:41 <cleobuline  > forthBot:  170141183460469231731687303715884105728 NUM-TO-BIN
2026-02-28 12:00:41 <forthBot    > 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2026-02-28 12:01:23 <veltas      > On desktop/laptop/phones/server it's useless, it's all 64-bit now.
2026-02-28 12:01:58 <veltas      > Mixed precision is good if you need arbitrary precision, you can implement it with that
2026-02-28 12:11:21 <KipIngram   > veltas: Of course - the whole game is different on a 32 bit platform.
2026-02-28 12:11:57 <veltas      > It's worth bearing in mind Forth was an embedded high level language with a niche in astronomy and business
2026-02-28 12:11:58 <KipIngram   > And yes - I'm a fan of bignum libraries.
2026-02-28 12:12:22 <KipIngram   > Yes again - I've always regarded embedded as Forth's natural home.
2026-02-28 12:12:23 <veltas      > So ran on a lot of 16-bit word size machines, and needed mixed precision
2026-02-28 12:12:49 <KipIngram   > The objections I made above apply only to 64-bit systems.
2026-02-28 12:13:08 <KipIngram   > And since I'm writing a 32-bit system right now, I may wind up feeling differently.
2026-02-28 12:13:32 <veltas      > 32-bit's good for a LOT, that's why they usually stopped there on 16-bit
2026-02-28 12:14:28 <KipIngram   > Well, and bignum starts to involve things that are not easy to hold on the stack, which means having somewhere in RAM to put them, and Forth normally didn't really offer any kind of dynamic memory  management (heap).
2026-02-28 12:14:41 <KipIngram   > It's the same reason there's usually not solid string support in Forth.
2026-02-28 12:15:12 <KipIngram   > They just arrived at a boundary of what was "easy and simple to implement."
2026-02-28 12:15:22 <KipIngram   > Without significant new complexities.
2026-02-28 12:15:30 <veltas      > PAD gets you pretty far
2026-02-28 12:15:43 <veltas      > And then the dictionary it's easy to add what you need
2026-02-28 12:15:43 <KipIngram   > Sure, for one quantity.
2026-02-28 12:15:54 <veltas      > Blocks/dictionary go far
2026-02-28 12:15:55 <KipIngram   > Of course - you can add anything.
2026-02-28 12:16:14 <KipIngram   > But I thought we were talking here about what came out of the tin.
2026-02-28 12:16:17 <veltas      > The problem is that people think in terms of general purpose programming, and Forth is truly optimised for its specialty
2026-02-28 12:16:29 <KipIngram   > Yes.
2026-02-28 12:16:47 <KipIngram   > It's "general purpose" only in the sense that it's more or less infinitely extensible.
2026-02-28 12:16:58 <veltas      > I would say that it's essentially "in the tin" if less than one block of code will give me e.g. an editor that's not useless and ability to move stuff around and through PAD
2026-02-28 12:17:29 <veltas      > And partly I can do that easily because the runtime that comes with Forth is designed to make it easy to add these things
2026-02-28 12:17:34 <KipIngram   > I have some quite high aspirations for it - I want to be able (on my otebook) to do scientific calculations a la Octave/Matlab.  And I want that to be convenient and easy.  But it won't come out of the box doing that.
2026-02-28 12:17:49 <KipIngram   > That will be a fancy add-on that I write, that invovles a replacement interpreter.
2026-02-28 12:17:57 <veltas      > So it's more like Forth has a lot of basic building-blocks words, but doesn't waste your ROM with stuff you might not need
2026-02-28 12:18:03 <KipIngram   > That I can run when I need those capabilities.
2026-02-28 12:18:13 <KipIngram   > Exactly.
2026-02-28 12:18:23 <KipIngram   > It's a lowest common denominator.
2026-02-28 12:19:08 <veltas      > But a good example someone gave in here, I think even implementing something as simple as strstr in Forth is a bit of a stack nightmare
2026-02-28 12:19:41 <KipIngram   > On the other hand, I think of what I am writing as an "operating system," and I want it to support multiple threads and sessions, strings, and so on.  So SOME of these capabilities I will put "in the tin."  Like I expect to have a more general memory management capability than Forth normally has at startup.
2026-02-28 12:20:00 <KipIngram   > Some of this stuff strikes me as "more or less universal" for *what I am wanting to do*.
2026-02-28 12:20:18 <KipIngram   > But if all I ever planned was embedded work, I don't think I'd see any need to add anything.
2026-02-28 12:20:26 <KipIngram   > (to the naked system).
2026-02-28 12:20:51 <veltas      > I'm writing a C-style language's compiler right now and the actual compiler is basically just a dictionary-style allocator because it uses less memory and makes perfect sense even for a compiler
2026-02-28 12:21:46 <KipIngram   > Oh, nice project; good luck with it.  I know "some" about commpilers (I've read the dragon book a couple of times over the years).
2026-02-28 12:22:05 <veltas      > I think it's amazing just how rare it is that you need more than a stack-style allocator
2026-02-28 12:22:23 <veltas      > The compiler I'm writing utilises almost none of the compiler theory
2026-02-28 12:22:31 <veltas      > The aim is to be really short, I'm hoping for well under 1000 lines
2026-02-28 12:22:42 <KipIngram   > Nice.
2026-02-28 12:22:52 <veltas      > It works much like the old C compilers worked, there's actually no state preserved between different top level defs
2026-02-28 12:23:12 <veltas      > The second a function or object def finishes all the internal memory is wiped
2026-02-28 12:27:00 <tulushev    > veltas: so basically the algo worked on ZX and was able to run with no modifications on desktop but less efficiently. But the challenge for me is a more practical example of having one program run on 32 and 64 bit systems with maximum performance. Either I need to assume all ints are 32 bit and have a performance hit on 64 bit or design for 64 and manually test if I'm overflow on 32, both are not great
2026-02-28 12:27:19 <veltas      > What you're after is totally impossible
2026-02-28 12:27:28 <veltas      > And there's no high-level programming language that works that way
2026-02-28 12:28:22 <tulushev    > Assuming 64 bit and dropping 32 bit and double cell operations seemed like a simpler approach
2026-02-28 12:28:33 <veltas      > Like on my laptop the fastest operations on integers are probably with MMX or something, and I've not seen a good compiler do that for you, it really devolves into writing assembly or something not far from assembly
2026-02-28 12:28:59 <veltas      > On ZX Spectrum the fastest approach would be probably batching and again a lot of stuff that needs assembly, no compiler will do that either
2026-02-28 12:32:28 <KipIngram   > Yes - when I do get around to doing this scientific computing I do hpe to do something better than just straightforward normal instructions.  I'd most like to use the GPU, but they don't make those very easy to bare metal program.
2026-02-28 12:33:00 <KipIngram   > s/hpe/hope/
2026-02-28 12:33:02 <veltas      > I wonder how fast GPUs can do integer arithmetic
2026-02-28 12:33:27 <KipIngram   > I would assume that under the right conditions quite fast, through parallelism, not individual operation speed.
2026-02-28 12:33:47 <KipIngram   > In scientific computing you're very often working with big matrices, so parallelism can really help.
2026-02-28 12:35:13 <KipIngram   > For a single integer operation I don't really see why a GPU would be any faster than a CPU, and the higher complexity of dispatching the data and gathering the result would make it a poorer option.
2026-02-28 12:35:42 <veltas      > Linear regression also benefits from parallelism a lot
2026-02-28 12:36:02 <KipIngram   > Sure - you can express it in matrix form.
2026-02-28 12:36:21 <veltas      > That's not how I'd think about that
2026-02-28 12:36:47 <veltas      > It's just a lot of independent calculations
2026-02-28 12:36:51 <KipIngram   > You *can*, though, and if you're wanting to see the parallelism in it it's a good way to view it.
2026-02-28 12:38:05 <KipIngram   > And if you already have a good system for matrix/vector operations in hand, that exploits some parallel capability, it might be the fastest way to implement a fast regression too.
2026-02-28 12:38:18 <KipIngram   > Rather than treating it as a new and wholly independent problem.
2026-02-28 12:40:18 <veltas      > Matrices aren't actually that parallel though(?), not as parallel as a load of 1-dimensional independent calculations(?)
2026-02-28 12:40:24 <veltas      > Or am I misunderstanding something
2026-02-28 12:40:38 <KipIngram   > It depends on what you're calculating, how well it can be exploited.
2026-02-28 12:41:06 <veltas      > Well I don't have to 'exploit' anything if I just look at it like a big OMP for loop that has totally independent calculations
2026-02-28 12:41:09 <KipIngram   > In matrix multiplication you can do all those individual row/column dot products in parallel.
2026-02-28 12:41:35 <KipIngram   > I'm not trying to claim it's the only way you could do a regression algorithm.
2026-02-28 12:41:59 <KipIngram   > But I do regard a general matrix/vector library as a more "basic" component than a regression.
2026-02-28 12:42:15 <KipIngram   > Even that, though depends on your aims.
2026-02-28 12:42:55 <veltas      > What's the famous one for fortran?
2026-02-28 12:42:56 <KipIngram   > For the sort of work I have in mind I'd need matrix/vector capability constantly, and I'd *sometimes* need regression.
2026-02-28 12:43:03 <KipIngram   > I don't know.
2026-02-28 12:43:30 <KipIngram   > I did some Fortan in 1982 and none since.  :-)
2026-02-28 12:43:48 <veltas      > BLAS
2026-02-28 12:44:03 <KipIngram   > Oh, the library.  I thought you meant a regression algorithm.
2026-02-28 12:44:13 <KipIngram   > Yes, BLAS is one of the famous numeric libraries.
2026-02-28 12:44:21 <veltas      > And if I remember right MATLAB is just a rip-off of BLAS, loads of stuff owes to it
2026-02-28 12:44:52 <KipIngram   > Sure - MATLAB is kind of a user interface put on top of such a library.
2026-02-28 12:45:09 <KipIngram   > User interface / scripting facility.
2026-02-28 12:45:18 <veltas      > I definitely question your point that optimised matrix libraries are fundamental, because the optimisations are so many and so complicated, it's not really the Forth way to look at it
2026-02-28 12:45:31 <veltas      > But if you want your own BLAS or similar then that's your business
2026-02-28 12:45:47 <KipIngram   > I didn't mean to imply they were "fundamental" in the sense that Forth should automatically support themm.
2026-02-28 12:45:54 <KipIngram   > They're fundamental for scientific computing.
2026-02-28 12:46:18 <veltas      > I don't have any experience to suggest either way, I'd be interested to see how I did without it
2026-02-28 12:46:45 <veltas      > I enjoy trying to strip away as much as possible, so of course I'd try and do same for scientific computing
2026-02-28 12:46:56 <veltas      > But yes I know that's very idiosyncratic
2026-02-28 12:47:37 <KipIngram   > Well, if you do *much* scientific computing, you'll see them pop up over and over.  But sure - I'm a fan of idiosyncratic approaches.  I could be accused of that in a lot of what I do.
2026-02-28 12:47:47 <KipIngram   > I like "doing without" as much as possible. :-)
2026-02-28 12:48:20 <KipIngram   > A lot of my general disapproval of the modern state of software is that we rarely do without anything.  We just keep on throwing more things in.
2026-02-28 12:48:58 <KipIngram   > To the point where understanding it all becomes a major hurdle.
2026-02-28 12:49:05 <veltas      > Yeah calc.exe says "are you sure you want to enable caret browsing?" when you try the keyboard shortcut to switch to octal the first time
2026-02-28 12:50:17 <veltas      > It's hard but it's fun an interesting to see what you can do with less, I know that's why you're playing with your RISC-V device
2026-02-28 12:50:17 <KipIngram   > On the subject of octal, I find the way C handles it unfortunate.
2026-02-28 12:50:50 <veltas      > Yeah blame Ken Thompson
2026-02-28 12:50:59 <KipIngram   > Before I knew much about C I wrote a bit of C that involved a little table of integers.  I wanted them to line up  nicely so I prepended 0's where necessary.
2026-02-28 12:51:10 <KipIngram   > I had no idea that was going to result in them being treated as octal.
2026-02-28 12:51:14 <KipIngram   > Learned the hard way.
2026-02-28 12:51:50 <veltas      > It's even worse in the original B compiler, it would parse 099 as 9*8 + 9
2026-02-28 12:51:51 <KipIngram   > I would prefer 8x<digits>.
2026-02-28 12:52:08 <KipIngram   > And if  you have that, then wny not just a general <base>x<digits>?
2026-02-28 12:52:31 <KipIngram   > Except then you might want very alrge bases, and x might need to be a digit, so I usually implement <base>:<digits>.
2026-02-28 12:52:51 <KipIngram   > And then support 0b<digits> and 0x<digits> as special cases.
2026-02-28 12:53:02 <veltas      > Well, there's strtol / strtoul in the standard runtime
2026-02-28 12:53:17 <KipIngram   > I don't know those.
2026-02-28 12:53:37 <veltas      > They're functions that parse an integer from a string, using a given base
2026-02-28 12:54:18 <KipIngram   > Ah.  Yes - "explicit" always works.
2026-02-28 12:54:54 <KipIngram   > <base>:<digits> is very clean to process.  You just start with base 10 and a zero accumulator, and go.  If you see a :, you copy the accumualtor so far to base, zero the accumulator, and carry on.
2026-02-28 12:55:08 <KipIngram   > It's literally a call back to yourself.
2026-02-28 12:55:34 <KipIngram   > Well, almost to yourself - you just skip that first line that sets base = 10.
2026-02-28 12:55:51 <veltas      > Wouldn't work in C because : is a punctuator
2026-02-28 12:55:56 <KipIngram   > Right.
2026-02-28 12:56:06 <veltas      > But you could use x like you said
2026-02-28 12:56:33 <veltas      > If it wasn't for UNIX history I wouldn't support octal at all in my C-style language
2026-02-28 12:56:53 <veltas      > But people would complain if they couldn't pass 0666 etc to chmod
2026-02-28 12:56:56 <KipIngram   > My NUMBER will treat letter digits (if the base makes them valid) as case insensitive if base is in the range 2..36.  Once base > 36, it switches case insensitivity.
2026-02-28 12:57:20 <KipIngram   > The most touchy part of it is properly skipping over those characters between 9 and A and Z and a.
2026-02-28 12:57:50 <KipIngram   > And integrating floating point support into it adds some complexity, of course.
2026-02-28 12:58:13 <KipIngram   > Though maybe not as much as you might think.
2026-02-28 12:58:32 <KipIngram   > It still winds up being one of my longer little clusters of definitions, though.
2026-02-28 12:58:42 <veltas      > I know exactly how much, I've implemented embedded libraries for floating point scanning/printing
2026-02-28 12:58:49 <KipIngram   > I think it's 20-something definitions in my most recent incarnation.
2026-02-28 12:59:22 <KipIngram   > All of them except NUM itself temporarily used.
2026-02-28 12:59:50 <veltas      > All so our embedded registry-style storage I created could support floating point as well ... a feature I predicted nobody would use
2026-02-28 12:59:53 <veltas      > And nobody did
2026-02-28 13:00:18 <veltas      > Total waste of time, but I know floating point really well now
2026-02-28 13:00:20 <KipIngram   > I meant specifically in this Forth NUMBER context.
2026-02-28 13:00:37 <KipIngram   > That's good knowledge.   There are a lot of ways to step on your toes using floating point.
2026-02-28 13:00:49 <KipIngram   > Do you know about posits?
2026-02-28 13:01:09 <veltas      > You've mentioned them before and I've already forgotten
2026-02-28 13:01:11 <KipIngram   > I think they're better, but I doubt they'll ever take over because there's too much legacy around the existing format.
2026-02-28 13:01:49 <KipIngram   > It's just an alternate way to do a float that the promoter shows very clearly gives better accuracy for most calculations over the whole range.
2026-02-28 13:02:02 <KipIngram   > Basically they involve a variable width exponent field.
2026-02-28 13:02:27 <KipIngram   > So there has to be a new field telling you how wide the exponent is, but it still winds up being an accuracy win.
2026-02-28 13:03:05 <KipIngram   > But if you use them you no longer have hardware floating point support, and no vendor is going to put hardware in for them because... no one uses them.  It's a catch 22.
2026-02-28 13:03:11 <veltas      > Really I think binary IEEE 754 is fine
2026-02-28 13:03:22 <KipIngram   > It is - it works very well.
2026-02-28 13:03:22 <veltas      > It's hard enough already for most people
2026-02-28 13:03:43 <veltas      > And already people are scared of the 'magic' where they shouldn't be
2026-02-28 13:03:46 <KipIngram   > It's just a little sad that we know there's a better way.  Not any kind of crisis, though.
2026-02-28 13:04:20 <KipIngram   > The standard has taken care of us fine for a long time, and will continue to do so.
2026-02-28 13:04:34 <KipIngram   > I just find the posits an interesting intellectual tidbit.
2026-02-28 13:04:36 <veltas      > The standard is very close to what literally everyone was doing already
2026-02-28 13:05:12 <veltas      > It's just slightly better for using an implicit leading 1 which not everyone was doing, and having a clear register mean +0.0
2026-02-28 13:05:15 <KipIngram   > And it's probably faster than a software posits implementation would be.  That variable exponent is one more thing you have to spend time considering.
2026-02-28 13:05:32 <veltas      > And also allowing integer comparison compare floats
2026-02-28 13:05:35 <KipIngram   > I don't recall that the video I watched on them addressed the performance side at all.
2026-02-28 13:06:08 <KipIngram   > I also don't recall whether posits give that up or not, but yes - that's definitely a nice thing.
2026-02-28 13:06:17 <veltas      > It's a true 'standard' because it borrowed from a number of innovations and joined them together nicely
2026-02-28 13:06:34 <MrMobius    > there was an interesting presentation on early FPUs that I really enjoyed. at the beginning, they were tearing parts out of calculators and wiring them into the bus since it was faster than soft floats
2026-02-28 13:06:41 <KipIngram   > I think you're reading to much into my words; I'm not trying to go on a crusade here.
2026-02-28 13:07:06 <veltas      > I think you're reading too much into my words, I'm not saying anything about your intentions
2026-02-28 13:07:21 <KipIngram   > :-)  Fair enough.
2026-02-28 13:07:25 <veltas      > I'm just talking about why IEEE-754 is good, as I understand it
2026-02-28 13:07:38 <KipIngram   > I agree with that - it works fine.
2026-02-28 13:07:52 <veltas      > I don't know anything about posits, I would wonder how it would compare in numbers of transistors
2026-02-28 13:08:16 <veltas      > The software performance could be worse yes but that's not really a big consideration, no serious floating point is done in software
2026-02-28 13:08:30 <KipIngram   > That's a good point too.  And that absolutely mattered back when this all started.  It matters less now - transistors are practically free.
2026-02-28 13:08:39 <veltas      > I don't think that's true
2026-02-28 13:08:53 <KipIngram   > I do - it's interconnecting them for various purposes that becomes the hard part.
2026-02-28 13:09:29 <veltas      > E.g. if you're looking at doing a pipelined 512-bit SIMD FPU then the transistors probably matter right?
2026-02-28 13:09:44 <veltas      > Impacts power usage too
2026-02-28 13:10:00 <KipIngram   > Definitely, and getting that heat out goes right along with that.
2026-02-28 13:10:34 <KipIngram   > That's the big reason graphene offers such potential possibilities - it has superior thermal characterstics over silicon.
2026-02-28 13:10:52 <KipIngram   > We could get the heat out a lot better, and so go to higher clock rates.
2026-02-28 13:10:53 <veltas      > And for many situations that power question is *the* limiting factor in performance
2026-02-28 13:10:59 <KipIngram   > Absolutely.
2026-02-28 13:11:26 <KipIngram   > That even turns out to be true in motors and generators - they're usually limited by the thermal behavior.
2026-02-28 13:12:45 <veltas      > So posits would not strictly be better if they used more transistors
2026-02-28 13:13:02 <veltas      > I am guessing they do ... if you don't have hardware subnormal support (which a lot of FPUs don't)
2026-02-28 13:13:26 <veltas      > I don't really know though
2026-02-28 13:40:17 <veltas      > My kid's just stolen my crisps from me
2026-02-28 13:40:35 <veltas      > I had a pack on the table and he just sat down and started eating them
2026-02-28 14:00:41 <forthBot    > Environment for cleobuline inactive, freeing...
2026-02-28 14:15:50 <veltas      > A font can't win me over if 1 and l look almost identical
2026-02-28 21:31:38 <KipIngram   > Amen.  Or O and 0.
2026-02-28 23:46:01 <KipIngram   > By the way, calling the code in the RAM buffer in the normal C parlance didn't work - for some reason gcc failed to save the return address in the appropriate RISCV registers.  Apparently it thought that call was never going to return.
2026-02-28 23:46:30 <KipIngram   > I had to do it with inline assembly like this:
2026-02-28 23:46:32 <KipIngram   >    __asm__ volatile (
2026-02-28 23:46:34 <KipIngram   >         "fence.i\n"
2026-02-28 23:46:36 <KipIngram   >         "jalr ra, %0, 0\n"
2026-02-28 23:46:38 <KipIngram   >         :
2026-02-28 23:46:40 <KipIngram   >         : "r"(ram)
2026-02-28 23:46:42 <KipIngram   >     );
2026-02-28 23:47:20 <KipIngram   > The fence.i instruction is required after modifying code ram and before executing it.  I don't have the precise reasons why nailed down, but that's why I included it there.
2026-02-28 23:53:13 <veltas      > Instructions and data are in different caches, fence.i is needed to make the changes consistent with the instruction cache