2022-04-27 04:37:22 <veltas      > Just realised you can use large bases to store numbers as text more compactly, or generate 'ID strings'
2022-04-27 04:37:26 <veltas      > decimal 23999986423 36 base ! . B0WZ01J  ok
2022-04-27 04:45:57 <dave0       > b0z0 !
2022-04-27 04:47:05 <dave0       > there's a real nice encoding base32 that uses the numbers 2-7 and letters A-Z ... i use it for passwords because it's human friendly and very easy to type
2022-04-27 04:47:29 <dave0       > notice it doesn't have 0 or 1 or 8 because O I B
2022-04-27 04:52:32 <veltas      > What about base 18, i.e. 0-9,A-H. I know 8/B look similar but I've not seen a font where they're indistinguishable
2022-04-27 04:52:59 <veltas      > decimal 23999986423 18 base ! . 233B5A031  ok
2022-04-27 04:53:21 <veltas      > I'm just trying to make it easier or ideally "do it for free" because Forth is the brutalist programming language
2022-04-27 04:57:09 <dave0       > 18 is definately a weird one :-)
2022-04-27 04:59:33 <dave0       > base 36 with `<# #>` and `number` to go back and forth (pun!) is really forthy :-)
2022-04-27 07:49:38 <veltas      > What would be interesting is a way of generating the intermediate output of GNU troff in FORTH, then we can use FORTH to write our documents
2022-04-27 07:49:49 <veltas      > And it will be fast unlike a solution involving TeX ;)
2022-04-27 08:48:07 <veltas      > As if by magic the x86 DIV instruction chains to allow easy multi-precision
2022-04-27 08:48:08 <veltas      > Okay it's not magic it's obviously intentional :P
2022-04-27 09:10:01 <dave0       > x86 has a couple of nice instructions for multi-precision
2022-04-27 09:10:32 <dave0       > MUL gives you a double precision result ie. 32 x 32 => 64
2022-04-27 09:10:50 <dave0       > and there is the multi-precision shifts SHLD and SHRD
2022-04-27 09:11:22 <dave0       > of course there's also ADC and SBB
2022-04-27 09:11:29 <dave0       > which are missing from RISCV
2022-04-27 09:26:05 <Zarutian_HTC> sorry, what are those instructions full names?
2022-04-27 09:26:10 <veltas      > I didn't know about multi-precision shifts! Thanks
2022-04-27 09:26:20 <veltas      > Zarutian_HTC: add with carry and subtract with borrow
2022-04-27 09:26:34 <veltas      > RISC-V doesn't have a carry/borrow bit
2022-04-27 09:27:11 <veltas      > Which is actually quite strange, their logic is it will save sillicon but it means chaining ops for higher precision is slower which potentially makes a lot of stuff inherently slower on the arch
2022-04-27 09:27:14 <Zarutian_HTC> i think risc-v does not have any status register but I might be wrong
2022-04-27 09:28:05 <veltas      > I think it's a properly silly mistake to make at the architecture level and they will always fail in benchmarks because of it
2022-04-27 09:28:36 <Zarutian_HTC> what? not having a status register?
2022-04-27 09:28:42 <veltas      > Yes
2022-04-27 09:29:19 <veltas      > Specifically not having an overflow bit, carry bit, etc or equivalent
2022-04-27 09:30:26 <Zarutian_HTC> the thing is that on most archs with status registers that register is hard to address, not like say IBM/370 conditioncode in the ProgramStatusWord
2022-04-27 09:31:29 <Zarutian_HTC> I like how the Mill does it though
2022-04-27 09:32:04 <Zarutian_HTC> the carry/overflow/borrow bits are just put on the belt
2022-04-27 09:33:52 <veltas      > You don't need to be able to address/refer to the register directly
2022-04-27 09:33:59 <veltas      > That's why I didn't say "status register"
2022-04-27 09:34:09 <veltas      > Because stuff like adc etc uses that bit automatically
2022-04-27 09:35:19 <veltas      > I don't care much for status registers, it's not necessary, but that bit needs to reside *somewhere* so we can string together multi-precision shifts/adds.
2022-04-27 09:35:45 <veltas      > Otherwise I end up handling that bit of state myself which means more branching or register usage
2022-04-27 09:36:56 <Zarutian_HTC> hard to address status register -> implict register, even for a bit and hard to save/restore
2022-04-27 09:40:52 <Zarutian_HTC> I think that one of the issues with register based machines is both the expendure of bits in the instruction to select the operands and destination and the cross bar matrix needed to implement it
2022-04-27 09:43:43 <Zarutian_HTC> with an dual stack machine that implements UM+ as the primitive for addition/subtraction you do not have to expend register to keep track of carry/borrow
2022-04-27 09:47:46 <veltas      > I guess that's true, but does RISC-V have an equivalent?
2022-04-27 09:48:46 <veltas      > In some architectures there is no add/sub without carry, you have to clear/set carry bit before using those
2022-04-27 09:49:04 <veltas      > But modern archs tend to just bite the bullet and have carry versions of those few ops that benefit
2022-04-27 09:50:01 <veltas      > 6502 doesn't have it, Z80 only had carry ops for some operations like 16-bit subtraction
2022-04-27 09:50:17 <veltas      > 6502 is only carry ops I mean
2022-04-27 09:50:27 <veltas      > And that's a notoriously small silicon
2022-04-27 09:51:58 <Zarutian_HTC> I dont recall but I heard that 6502 has four metal layers? makes it easy to route such bits around
2022-04-27 09:52:24 <Zarutian_HTC> but also 6502 is an accumulator based arch
2022-04-27 09:54:15 <dave0       > veltas: regarding risc-v and no carry bit, i read a nice idea that it should have an "add-high" instruction, where it does a multiprecision add (eg. 32 + 32 => 64) and throws away the lower word ... it's interesting because it matches a "multiply-high" insutrction that i believe it already has
2022-04-27 09:54:38 <veltas      > That's what Zarutian_HTC said earlier and I said was a valid alternative
2022-04-27 09:54:47 <dave0       > oh i missed it!
2022-04-27 09:54:55 <dave0       > nice idea!
2022-04-27 09:54:56 <veltas      > But IMO it's still not quite as good
2022-04-27 09:55:06 <veltas      > But it should give sufficient performance
2022-04-27 09:55:39 <dave0       > it would be an improvement over a conditional branch and an incement
2022-04-27 09:59:06 <veltas      > Yeah exactly
2022-04-27 10:03:38 <Zarutian_HTC> dave0, vektas: you two heard me here describe that Forth VMs in SIMD idea the other day?
2022-04-27 10:03:47 <Zarutian_HTC> veltas*
2022-04-27 10:04:23 <veltas      > Nope I missed that
2022-04-27 10:08:59 <MrMobius    > leaving out the status status reg simplifies pipelining
2022-04-27 10:10:00 <MrMobius    > on x86 for example when it tries to schedule operations in parallel where the carry is needed the processor stalls
2022-04-27 10:10:10 <Zarutian_HTC> veltas: dont have time right now but it was a few days ago and should be in the public logs
2022-04-27 10:10:56 <veltas      > MrMobius: You can say that about any register used in arith
2022-04-27 10:11:26 <veltas      > Unless you're meaning that the bit is shared with too much, or with too many other bits, in which case keeping just the bit itself and not status register makes sense
2022-04-27 10:11:32 <veltas      > But removing status register entirely makes no sense
2022-04-27 10:11:44 <veltas      > Sorry I mean removing the carry bit entirely makes no sense
2022-04-27 10:12:23 <MrMobius    > veltas, no actually if you pipeline them and each relies on the last, you pay no penalty in RISC
2022-04-27 10:12:32 <MrMobius    > its a big performance boost
2022-04-27 10:12:38 <veltas      > And how often do compilers generate instructions where carry is needed?
2022-04-27 10:12:53 <MrMobius    > also when do you need a carry with 64 bit regs?
2022-04-27 10:13:05 <veltas      > Very rarely
2022-04-27 10:13:18 <veltas      > But when you do risc-v is going to have bad performance
2022-04-27 10:13:26 <MrMobius    > right so no big deal to leave it out
2022-04-27 10:13:30 <veltas      > Anything with arbitrary precision arith, so Python and a lot of maths
2022-04-27 10:14:32 <veltas      > It's not a 'big deal' but the arch has designed something with inherently worse performance in certain situations that processors classically have been able to handle specially
2022-04-27 10:14:47 <MrMobius    > even then you get good performance. there are ops to set a register om comparison so no branching needed
2022-04-27 10:14:49 <veltas      > So I am watching from the sidelines and waiting for failure
2022-04-27 10:16:12 <veltas      > libgmp person agrees with me... I guess we'll just see in practice who's right
2022-04-27 10:16:15 <MrMobius    > ya im not convinced either but youve probably noticed RISC is nearly identical to MIPS architecturally so you have 25 years of data too see id that type of processor is slow or unusable
2022-04-27 10:16:22 <MrMobius    > and it certainly is not
2022-04-27 10:16:31 <veltas      > Does MIPS have no carry bit?
2022-04-27 10:16:36 <MrMobius    > whetyer industry adopts it is another issue
2022-04-27 10:16:48 <MrMobius    > correct
2022-04-27 10:18:05 <MrMobius    > i mostly do 6502 asm but have been doing mips lately. trust me, you dont miss the status register
2022-04-27 10:38:38 <veltas      > Always interesting talking about architectures
2022-04-27 11:49:06 <KipIngram   > I can play with bases up to 62 on my system.  :-)
2022-04-27 11:49:24 <KipIngram   > I carried some subtle bugs in that for a while, but I think I've got them all wrung out now.
2022-04-27 11:49:31 <KipIngram   > 0-9 A-Z a-z
2022-04-27 11:50:05 <KipIngram   > For base 36 and below, A-Z and a-z are case insensitive - you don't need both sets of letters up to there.
2022-04-27 11:50:41 <KipIngram   > So for hex I can use either.
2022-04-27 11:52:21 <KipIngram   > The bugs mostly involved it either generating or failing to reject characters between '9' and 'A' or 'Z' and 'a'.
2022-04-27 11:54:17 <KipIngram   > I have a BASE variable (at least currently) but it only affects output.  For input parsing I specify non-decimal base right there in the string.
2022-04-27 11:54:38 <KipIngram   > I *probably* should modify the output stuff so it puts that base back into the output string, but right now it doesn't.
2022-04-27 11:55:26 <KipIngram   > 18 base !  ok
2022-04-27 11:55:28 <KipIngram   > 18:123G73 . 123G73  ok
2022-04-27 11:56:47 <KipIngram   > Having the base out in front like that works out well - NUMBER always starts off using base 10, but if it finds a : char then it takes whatever it's got so far, uses it as base for the rest, and clears the accumulator back to 0.
2022-04-27 11:57:50 <KipIngram   > The integer stuff was all fairly clean and straightforward - making it handle floating point properly was kind of a pain.  I'll likely re-write it sometime to make it easier to follow.
2022-04-27 16:47:40 <veltas      > KipIngram: Base 62 sounds even better
2022-04-27 17:00:26 <Zarutian_HTC> KipIngram: re input bases, you support 0b____ 0q____ 0o_____ 0x____ notation?
2022-04-27 19:18:12 <KipIngram   > For hex I allow x: as well as the default 16: and for binary I allow b: as well as 2:
2022-04-27 19:18:44 <KipIngram   > I don't do much with binary, except when I'm deliberately testing the stuff, but I typically will write x: for hex.
2022-04-27 19:19:17 <KipIngram   > Probably wouldn't be too hard to make 0x etc work too.
2022-04-27 19:19:48 <KipIngram   > So long as the "indicating character" comes before the actual result digits, it would fit fairly easily into the structure.
2022-04-27 19:21:19 <KipIngram   > When I see x, I push 16 to the base (which is in a stack cell) and then skip over the : (though I check for it and error if it's not there).  I'd probably just need to hop over that skip/check to mke 0x... work.
2022-04-27 19:21:50 <KipIngram   > If I insisted that the leading 0 be there, that might be a harder change.
2022-04-27 19:23:58 <KipIngram   > 62:KipIngram . 4524667191033084  ok
2022-04-27 19:24:04 <KipIngram   > I guess that's "my number."
2022-04-27 19:27:14 <Zarutian_HTC> well, I just check if the first two characters in an 'word' not found in the dictionary match above list and set BASE temporarly to that then lopp these two off and just pass the rest to NUMBER
2022-04-27 19:31:37 <KipIngram   > Yeah.  I use a stack frame for NUMBER.  The frame has a character pointer, the base, a flags register, and the accumulator.  Base and accumulator get initialized to 10 and 0, and I just start processing characters.  x and b get some special handling - in the general case if I come to : I just move accumulator to base, zero the accumulator, and carry on.
2022-04-27 19:32:56 <KipIngram   > A decimal point says it's a floating point number - that makes the number I'm building be an integer mantissa.  That sets a flag, and if that flag is set I increment a counter - I use that to adjust the exponent value later.
2022-04-27 19:33:17 <KipIngram   > The exponent itself gets handled with a recursive call to a component of NUMBER.
2022-04-27 19:34:07 <KipIngram   > When I finish all the characters of a float, I have a big integer, a decimal place count, and another integer that's the exponent.  I use the FPU to turn those into an IEEE pattern.
2022-04-27 19:35:12 <KipIngram   > That turned out to be a tad tricky, because one of the FPU instructions you need requires that the input value be between -1 and 1, and it's not necessarily so; a little dance is required for that.
2022-04-27 19:37:59 <KipIngram   > It's easy enough to save that quantity as an integer, reload that integer and subtract.  But you have to remember that integer and multiply or divide by 2^<that integer> later.
2022-04-27 19:38:19 <KipIngram   > It's a kind of interesting collaboration between the CPU and FPU.
2022-04-27 19:40:55 <KipIngram   > You might remember a month ago or so I was talking about throwing errors on overflow.  I wound up taking that back out, because it just doesn't seem to be common behavior, but the main reason for that was because giving a floating point number with too many decimal places will foul up the resulting float.
2022-04-27 19:41:27 <KipIngram   > I decided that just wasn't the right way to handle it - maybe at some point I'll look into checking for it just within NUMBER and ignoring any further decimal places.
2022-04-27 19:41:52 <KipIngram   > That would be the best behavior - you'd get the best number possible, even though not as good as you were trying for.
2022-04-27 19:42:43 <KipIngram   > Probably not really necessary - I don't really see ever trying to use that many decimal places in a number.
2022-04-27 19:43:04 <KipIngram   > For special constants like pi and e and so on I'll just figure out how many will work and use that.
2022-04-27 19:43:39 <KipIngram   > And when I actually define those constants I may just specify the 64-bit hex pattern.
2022-04-27 19:55:56 <KipIngram   > eris: why are thse not the same?
2022-04-27 19:55:59 <KipIngram   >       ≢⍴cuboid - 1
2022-04-27 19:56:01 <KipIngram   > 3
2022-04-27 19:56:03 <KipIngram   >       ¯1+≢⍴cuboid
2022-04-27 19:56:05 <KipIngram   > 2
2022-04-27 19:56:31 <KipIngram   > The - 1 just seems to be ignored.