00:00:00 --- log: started forth/19.01.30
00:20:38 --- quit: cantstanya (Remote host closed the connection)
00:23:01 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
00:38:55 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth
00:44:41 --- quit: pierpal (Quit: Poof)
00:45:00 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth
01:16:36 <proteusguy> bspin is back. logging has returned!
01:29:03 <rdrop-exit> Cool! Thanks for the heads-up proteusguy
01:44:39 --- quit: proteusguy (Remote host closed the connection)
01:45:26 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
01:46:16 --- quit: pierpal (Ping timeout: 244 seconds)
01:49:21 --- quit: MrMobius (Ping timeout: 272 seconds)
01:49:21 --- nick: [1]MrMobius -> MrMobius
02:03:45 --- quit: ashirase (Ping timeout: 245 seconds)
02:05:00 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
02:05:00 --- mode: ChanServ set +v proteusguy
02:09:37 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:55:48 --- quit: dave0 (Quit: dave's not here)
03:25:20 <crc> proteusguy: I have a shell account on the server that hosts the logs; I rsync with that
03:34:53 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth
03:55:26 --- quit: pierpal (Ping timeout: 244 seconds)
04:02:01 --- join: pierpal (~pierpal@host171-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
04:26:32 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:52:37 --- join: `presiden (~presiden@unaffiliated/matematikaadit) joined #forth
04:53:18 <proteusguy> crc you mean on bespin?
05:02:11 <crc> yes
05:03:22 --- quit: probonono (Ping timeout: 240 seconds)
05:07:55 --- quit: dddddd (Ping timeout: 245 seconds)
05:13:30 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
05:14:35 <WilhelmVonWeiner> Anyone who says Forth is not a metacompiler needs a SLAP
05:14:47 --- join: probonono (~User@unaffiliated/probonono) joined #forth
05:17:46 <rdrop-exit>  To the matresses!
05:21:52 <siraben> Forth is a purely functional, lazy, garbage-collected, strongly typed lanugage. /s
05:23:06 <WilhelmVonWeiner> strongly typed, but the only type is signed ints
05:23:31 <WilhelmVonWeiner> I also think you can model forth as a functional system
05:23:42 <WilhelmVonWeiner> I don't know lambda calculus, though.
05:23:42 <proteusguy> can't call it "purely" functional.... more like concatenative.
05:23:46 <siraben> I like to think of words as "pure functions"
05:23:50 <siraben> Not a lot of my words have side-effects
05:23:59 <WilhelmVonWeiner> concatenative isn't functional?
05:24:04 <proteusguy> yes you can implement functional systems of course - but forth doesn't enforce it.
05:24:18 <proteusguy> concatenative doesn't guarantee statelessness.
05:25:04 <WilhelmVonWeiner> What elements of state are there in Forth? The stacks, the dictionary, memory
05:25:33 <WilhelmVonWeiner> Maybe I don't get "statelessness".
05:25:44 <proteusguy> and variables - pretty much anything any other von Nuemann language has.
05:25:54 <rdrop-exit> "There's always state what differentiates different approaches is where it is kept." - C.Moore
05:26:20 <proteusguy> forth has the same states as C or anything else. it's decidedly not inherently a functional language.
05:28:28 <proteusguy> it *is* a pointfree language, however, which is a nice feature for those wanting to do functional.
05:28:58 <WilhelmVonWeiner> I think you can model variables in Forth statelessly though unless I'm severly confused about how pure functionality works
05:29:11 <WilhelmVonWeiner> because defining a variable is a transform of a dictionary into a new dictionary
05:30:35 <siraben> State can be done via the stack, yes. Which also means it's easy to compose things
05:31:05 <siraben> But in Forth the very act of defining a new word mutates the heap
05:31:46 <WilhelmVonWeiner> in canonical Forth I guess
05:32:34 <corecode> i wonder how much smaller i could make my cpu if i made it an 8bit machine
05:32:59 <corecode> with multi cycle for lit/branch/call
05:45:08 <proteusguy> WilhelmVonWeiner, sure you CAN but you also CAN using assembly language. There's nothing inherent in the language that enforces the restriction.
06:03:03 <rdrop-exit> "Forth was designed to 'avoid the 'unsolvable' problems in computer science. The 'real' problem is the problem you want to solve. Adding unsolvable problems to the real problem is really your problem."
06:06:22 <proteusguy> :-) That a Chuck quote or someone else?
06:06:39 <rdrop-exit> Jeff Fox paraphrasing Chuck
06:06:49 <proteusguy> Good attitude.
06:08:15 <rdrop-exit> "Forth is highly factored code." -- C.Moore
06:11:33 <rdrop-exit> "Simplicity is a prerequisite for reliability" -- Djikstra
06:13:28 <rdrop-exit> I have a whole notebook of quotes that I've found useful over the years
06:14:41 --- quit: proteusguy (Ping timeout: 250 seconds)
06:14:55 <rdrop-exit> "Any computer "We shape our tools and afterwards our tools shape us." -- Marshall McLuhan
06:15:11 <rdrop-exit> Oops
06:15:18 <rdrop-exit> I'll try again:
06:15:24 <rdrop-exit> We shape our tools and afterwards our tools shape us.
06:15:33 <rdrop-exit> -- Marshall McLuhan
06:18:43 <rdrop-exit> All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection. -- corollary to David J. Wheeler's aphorism
06:19:37 <rdrop-exit> AKA Over-Abstraction
06:24:20 <rdrop-exit> I like to reread the entire notebook every few months.
06:24:44 <siraben> I have a notebook on Forth, going from first understanding NEXT to my OS
06:24:59 <Zarutian> talking about annoying things in programming. I was trying to figgure out why there was an 'embarrasing gc pause' in a C++ program even when the culprit objects were area alloced.
06:25:03 <siraben> Not including many dozens of blank papers I used to trace out assembly code
06:25:17 <rdrop-exit> Last one for tonight:
06:25:20 <rdrop-exit> Compatibility means deliberately repeating other people's mistakes. -- another David J. Wheeler aphorism
06:25:24 <siraben> Ugh, GC, hits you when you least need it to
06:25:42 <Zarutian> Do you know what the problem was? One object of a class that followed the idiotic RAII 'principle'.
06:25:47 <siraben> I'll try to learn Rust later, I've heard good things about its type system and borrow checker
06:26:58 <Zarutian> So the runtime was checking if every object in that area had an deallocator override instead of just returning the entire area to the memory allocation system like it was supposed to do.
06:27:16 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
06:27:16 --- mode: ChanServ set +v proteusguy
06:28:01 <Zarutian> siraben: well, depends. In some runtimes (not C++ for sure) the garbage collection is rather concurrent and not only run when the memory allocator is asked for more memory
06:30:18 <Zarutian> and in some runtimes that do not support concurrency but use event-loop then garbage is collected at each event-loop 'turn' (basically at the end of the loop before it repeats)
06:30:58 <Zarutian> prevents the piling up of garbage that causes long collection pauses.
06:32:59 <corecode> Zarutian: ok, my cpu is complete (for now)
06:33:06 <corecode> you may reveal your opcodes
06:34:08 <rdrop-exit> Drum roll please.
06:34:12 --- quit: nighty- (Remote host closed the connection)
06:35:29 <Zarutian> right, those are NOP UM+ AND XOR 1LBR 1+ @ ! DUP DROP SWAP SKZ >R R> SPES EXIT
06:35:53 <Zarutian> 1LBR is 1 LeftBitRotate
06:36:15 <Zarutian> SKZ is SKip next instruction if Zero
06:36:57 <Zarutian> an instruction is eather a primitive like those enumerated or a call to that address
06:37:33 <Zarutian> basically if the first three nybbles of an instruction is 0x000 then it is a primitive otherwise it is a call
06:38:00 <corecode> ok
06:38:40 <Zarutian> SPES is eather just a NOP but then I/O is memory address space mapped or it does SPECIAL things such as I/O or other relatively infrequent operations
06:39:09 <corecode> how do you branch?
06:39:34 <Zarutian> like JMP (branch) and BRZ (0branch) ?
06:39:38 <corecode> yes
06:40:11 <Zarutian> well : JMP R> @ >R ; works for JUMP (where the next cell is the destination)
06:40:52 <corecode> you use that for flow control?
06:41:32 <Zarutian> BRZ is similiar. It uses ?: to pick between two destinations.
06:41:39 <Zarutian> yes, why not?
06:42:03 <corecode> seems a bit high overhead
06:42:05 <corecode> but okay
06:42:21 <corecode> what is UM+
06:42:37 <rdrop-exit> What were the deisgn objectives that led you to this ISA?
06:42:43 <Zarutian> overhead? invoking subroutines on dual stack machines is cheap.
06:43:55 <Zarutian> rdrop-exit: have the primitive as brutalicly simplistic as possible to easy microcode/hardwiring in BLIFF (or other equiv boolean wire definition language)
06:44:29 <corecode> do you have it running in an fpga?
06:44:32 <Zarutian> corecode: UM+ has the stack effect of ( a b -- sum carry )
06:44:58 <corecode> what's leftbitrotate
06:45:02 <corecode> rotate left?
06:45:28 <Zarutian> corecode: nope. Dont even own such a device. Was doing this for Secure Multi Party Computation purposes.
06:45:51 <Zarutian> yebb rotate the bits one bit to the left
06:46:16 <Zarutian> s/primitive/primitives/
06:47:00 <corecode> so how do you do a shift right by one?  repeat this rotate 15 times?
06:48:03 <zy]x[yz> followed by a mask, presumably
06:48:19 <Zarutian> yeah, pretty much
06:49:28 <corecode> ok
06:54:17 <proteusguy> Zarutian, what size are your instruction codes? They full cells?
06:54:31 <Zarutian> proteusguy: full cells
06:55:34 <Zarutian> it means that in this ISA direct calls to the first sixteen cells of memory are inexpressible but that isnt such of a huge deal
06:59:45 <corecode> 16
07:16:28 <rdrop-exit> Each one of those 16 instructions uses a full cell?
07:17:10 <rdrop-exit> Or you pack multiple opcodes per cell?
07:17:35 <Zarutian> one opcode per cell, the lower most nybble the others are 0
07:19:08 <rdrop-exit> That's rather odd, your ratio of "work" instruction bit is going to be very low.
07:19:27 <rdrop-exit> * "worl" per instruction bit
07:19:46 <rdrop-exit> * "work" per instruction bit
07:19:59 <rdrop-exit> I can't type worth a damn
07:20:30 <corecode> yea my instruction density isn't high either
07:21:28 <Zarutian> then again there are quite a few short non-primitive words that get lot of use
07:21:48 <rdrop-exit> If you're going to have only 16 instructions, you might as well pack multiple instructions per machine word
07:22:45 <Zarutian> nope, too much hassle (or circuit complexity) decoding them out plus return addresses are only of cell size granularity
07:22:47 <rdrop-exit> Or else you'll be wasting a lot of instruction memory bandwidth just fetching zero bits
07:23:08 <rdrop-exit> that are just padding
07:23:49 <Zarutian> if any of the upper three nybbles are non zero, that indicates the instruction is a call
07:24:22 <Zarutian> so, not that much wastage per se
07:25:06 <rdrop-exit> Ok, but ultimately you always reach non-call cells
07:25:27 <rdrop-exit> that do the real work
07:25:30 <Zarutian> but as always it is a trade off against other concerns
07:26:26 <corecode> did you implement it in HDL?
07:26:39 <rdrop-exit> Yes, engineering is all about the trade-offs
07:28:32 <Zarutian> corecode: havent yet implemented it in the usual HDL languages. Only a small VM in C and a half complete wires&gates logic simulator in javascript.
07:28:45 <corecode> ok
07:28:59 <corecode> i would be interested in the number of gates/LUTs
07:29:02 <Zarutian> turns out that neither VHDL nor Verilog deals well with parametic compositions of modules
07:29:32 <rdrop-exit> SystemVerilog is better at it
07:29:41 <corecode> parametric how?
07:30:04 <rdrop-exit> Gotta walk the dogs, catch you all tomorrow. Keep on Forthin'
07:30:15 --- quit: rdrop-exit (Quit: Lost terminal)
07:31:23 <Zarutian> corecode: lets say I want a seperate stack module. (Basically a memory with an up&down counter register attached to its address port)
07:32:09 <Zarutian> corecode: specifing the depth of the stack, the bit width of the cell, is the underlaying memory single, dual or quad ported and so on.
07:32:45 <corecode> you just pass parameters?
07:33:54 <Zarutian> well, I havent dug proprerly into verilog but does that support modules being first class values? That is passed as paratmeters
07:34:03 <corecode> no
07:34:18 <corecode> i don't think so
07:35:11 <Zarutian> sometimes for speed sake, I subsitute out an fully wire&gate'd memory module for a one that is basically an variable and an array
07:35:24 <Zarutian> s/speed/simulation speed/
07:36:26 <corecode> sure
07:39:08 <Zarutian> or change around how big some ROM look up tables (because they are a bit faster than doing the combinational logic in some cases) that is being used internally in the adder, the PC incrementer and such.
07:40:11 <corecode> what's your speed target?
07:42:05 <Zarutian> well, as this is meant for a boolean circuit that is run via SMPC, about 16 tau per instruction max.
07:42:23 <Zarutian> Tau being half the round trip time between SMPC nodes.
07:42:54 <corecode> now i get what you're doing
07:42:56 <corecode> okay
07:44:26 <Zarutian> the two input AND gates are the main culprit as an Secret Sharing of their intermediatary result is what takes up a tau
07:45:50 <Zarutian> so, I use various tricks such as the one from J1 where the adder is continously fed TOS and NOS as the inputs
07:46:39 <Zarutian> then what new TOS should be is just selected via a mux
07:47:14 <corecode> yea that's what my cpu does
07:51:12 <Zarutian> all this to get a spefication made up of AND gates, XOR gates, INputs, OUTputs and delay MEMory 1 bit cells.
07:51:38 <Zarutian> and how these are wired together.
07:51:59 <Zarutian> bbl
09:03:13 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
09:06:38 --- quit: MrMobius (Ping timeout: 246 seconds)
09:06:38 --- nick: [1]MrMobius -> MrMobius
09:34:53 --- join: dys (~dys@tmo-102-39.customers.d1-online.com) joined #forth
09:47:17 --- quit: dys (Ping timeout: 244 seconds)
09:47:31 <proteusguy> Zarutian, since those first 16 cells can't be code, you could do something like the 6502 and map your registers to those addresses.
09:48:51 <proteusguy> Zarutian, perhaps try out MyHDL as a more expressive option for your implementation language -> HDL?
09:52:39 <corecode> i think Zarutian doesn't want to run it in hardware, but only in simulated hardware for secure multiparty computation
09:52:57 <corecode> for that it basically becomes a configurable state machine
09:57:13 <proteusguy> Right - MyHDL includes an extremely fast simulation capability.
09:58:37 <proteusguy> Here's a great intro video from 5 years ago. It's vastly improved since then but already quite impressive: https://www.youtube.com/watch?v=LSgOpvr8FII
10:08:45 --- join: xek_ (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
10:11:15 --- quit: xek (Ping timeout: 245 seconds)
10:29:02 --- join: dys (~dys@tmo-102-218.customers.d1-online.com) joined #forth
11:23:49 --- quit: gravicappa (Ping timeout: 240 seconds)
11:24:58 --- join: darithorn (~darithorn@75.174.231.56) joined #forth
11:47:36 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
11:49:07 --- join: gravicappa (~gravicapp@h109-187-44-245.dyn.bashtel.ru) joined #forth
12:04:32 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
12:08:17 <dave0> hi
12:18:33 <crc> hi dave0
12:20:45 <dave0> hi crc
12:26:02 --- quit: gravicappa (Ping timeout: 250 seconds)
12:27:50 <WilhelmVonWeiner> hey dave0
12:27:54 <WilhelmVonWeiner> what you working on 
12:28:47 <dave0> hi WilhelmVonWeiner 
12:29:07 <dave0> i'm trying to uninstall all the lenovo shovelware on my computer :-(
12:30:30 <dave0> i turned on the computer this morning and it helpfully popped up a message that it upgraded something, then it redirected me to a dodgy website
12:30:49 <dave0> so i thought i'd try and wipe it from my computer
12:30:57 <WilhelmVonWeiner> Switch to OpenBSD :^)
12:31:44 <dave0> i have NetBSD on the other laptop... it's a bit fiddly
12:31:58 <dave0> i don't really like unix either heh
12:32:12 --- join: mykespb (~myke@213.141.133.133) joined #forth
12:32:14 <dave0> there's no alternative to windows
12:32:21 <dave0> no competition
12:34:32 <Kumool> sure there is, you just cant be a "user" on the others
12:34:39 <WilhelmVonWeiner> depends what you're doing
12:34:50 <WilhelmVonWeiner> Nothing I do requires any WinCuck software
12:35:03 <dave0> i want irc and youtube
12:35:03 <WilhelmVonWeiner> WangBlows MicroSchlong vs OpenBSD
12:35:18 <Kumool> haiku apparently works
12:35:27 <Kumool> riscos,plan9
12:35:32 <WilhelmVonWeiner> Haiku looks awesome but I don't want a system written in C++
12:35:38 <WilhelmVonWeiner> very focused on gui too
12:35:50 <Kumool> nothing wrong with GUIs
12:36:06 <WilhelmVonWeiner> nothing wrong with them per se
12:36:22 <Kumool> programmers don't know how to make GUIs or make them useful
12:36:43 <WilhelmVonWeiner> I think that's mostly specific to the GNU project
12:37:03 <john_cephalopoda> Not many people actually know how to design a good UI.
12:37:20 <john_cephalopoda> iOS apparently has a pretty decent UI.
12:37:35 <Kumool> as much as I hate apple, they do WIMPs well
12:37:50 <Kumool> could be better, but its ok
12:38:01 <john_cephalopoda> I used MacOS on an iMac and wasn't very impressed by the UI. 
12:38:05 <WilhelmVonWeiner> This job I'm going to everyone seems to use MacOS
12:38:25 <WilhelmVonWeiner> the guy interviewing me uses Linux though. Sighed a sigh of the highes relief
12:38:34 <Kumool> that's a good thing, the UI needs to be the least interesting thing, just get out of the way
12:38:47 <WilhelmVonWeiner> that's why I use FVWM on OpenBSD
12:38:53 <WilhelmVonWeiner> default, just werks
12:39:20 <dave0> heh
12:39:28 <Kumool> I remember people where whining over googles simple search bar a couple of years back, like, its a search bar! dont put bells and whistles, it doesnt need none of that
12:39:38 <dave0> when i sit at some unix computer the first thing i do is fire up xterm
12:39:53 <WilhelmVonWeiner> and use it to install rxvt?
12:40:00 <dave0> haha
12:40:02 <Kumool> :D
12:41:13 <Kumool> something annoyed me yesterday, people where talking about putting a keyup event in terminals, nobody saw the usability on it
12:41:14 <john_cephalopoda> mlterm supports sixels.
12:42:09 <Kumool> speaking of GUIs, have any of you seen arcan?
12:42:18 <crc> dave0: I only use Windows at work. It's the most annoying of the systems I use.
12:42:35 <Kumool> https://arcan-fe.com/
12:43:19 <WilhelmVonWeiner> crc: install emacs
12:43:27 <WilhelmVonWeiner> comes with eshell which is a free POSIX shell
12:45:11 <Kumool> POSIX shells, another horrible thing
12:46:20 --- quit: xek_ (Remote host closed the connection)
12:46:48 --- join: xek_ (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
12:47:35 <dave0> damn windows... sometimes a program won't start. click a second time and it works
12:47:45 <dave0> how can a program just not start?
12:51:12 <zy]x[yz> every windows since vista has had this terrible UI feedback problem
12:51:39 <zy]x[yz> if you click something and it takes, but just takes a long time, you get no visual feedback indicating it got your input and you just need to wait
12:51:55 <zy]x[yz> blows my mind that people pay for that
12:52:55 <crc> WilhelmVonWeiner: I'm not sure I can handle the modifier key combinations
13:03:54 --- quit: xek_ (Ping timeout: 268 seconds)
13:05:16 --- quit: mykespb (Quit: Leaving)
13:26:15 --- quit: djinni (Ping timeout: 245 seconds)
13:27:36 --- join: djinni (~djinni@68.ip-149-56-14.net) joined #forth
13:32:08 --- quit: mtsd (Quit: WeeChat 1.6)
15:22:40 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
15:22:51 <rdrop-exit> Greetings Forthlings!
15:38:50 <john_cephalopoda> Hi rdrop-exit 
15:38:55 --- quit: darithorn (Quit: Leaving)
15:39:02 <rdrop-exit> Hi John
15:44:20 <crc> good evening rdrop-exit 
15:44:58 <rdrop-exit> Good morning crc
15:58:27 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
16:01:18 --- join: [2]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
16:01:25 --- quit: MrMobius (Ping timeout: 250 seconds)
16:04:27 --- quit: [1]MrMobius (Ping timeout: 250 seconds)
16:05:21 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
16:07:18 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:27:20 <`presiden> Good afternoon all
16:28:10 --- quit: [2]MrMobius (Quit:  HydraIRC -> http://www.hydrairc.com <- Organize your IRC)
16:28:47 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
16:42:58 <rdrop-exit> Hi `presiden
16:43:33 <PoppaVic> hmm
16:57:00 <PoppaVic> I'm "entertaining myself" by seeing how we MIGHT create primitives from opcodes.. Which reduces the set-size..
17:00:37 <tabemann> hey guys
17:00:53 <rdrop-exit> Hi PoppaVic, hi tabemann
17:00:59 <PoppaVic> hiya
17:01:29 <rdrop-exit> In what context PoppaVic?
17:02:34 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
17:03:00 <PoppaVic> rdrop-exit: well, I started with NGA ops; abused them a little. Then I added an Optional set taking 5 more bits. Now, I am trying to see how many ops I can reduce to seq of OTHER ops - to see which must be ops and which can be idiom
17:04:30 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:04:53 <PoppaVic> rdrop-exit: so, for example: 
17:05:00 <PoppaVic> DROP,SWAP, >R, R>, R@  as opcodes (microcode):
17:05:00 <PoppaVic>     Dup:        >r r@ r>
17:05:00 <PoppaVic>     Over:       >r {dup: >r r@ r>} r> swap
17:05:00 <PoppaVic>  
17:05:09 <rdrop-exit> I'm not familiar with NGA, are you speaking of tabemann's TTC VM?
17:05:39 <PoppaVic> rdrop-exit: I think it's CRC's, might be i4/marks
17:05:50 <tabemann> PoppaVic probably isn't
17:06:03 <PoppaVic> forthworks.com
17:08:10 <dave0> that's not dup! dup is   0 pick    and over is   1 pick
17:08:23 <PoppaVic> dave0: back to yer cave
17:08:32 <dave0> lol
17:08:51 <rdrop-exit> You can always reduce the number of opcodes, but if it's for a software-based VM you can quickly reach dimininishing returns.
17:09:01 <PoppaVic> I have never hidden from PICK or ROLL, but I am now trying to reduce the whole opcode set
17:09:09 <tabemann> I didn't feel the need to be too minimalistic (even though I am implementing OVER as 1 PICK)
17:09:27 <PoppaVic> rdrop-exit: well, of course. My point is to see what I can gain, since opcode-packing occurs as well
17:09:48 * tabemann for one is not afraid of PICK or ROLL either
17:10:01 <rdrop-exit> I have never used or implemented PICK or ROLL, as Chuck says they are abominations.
17:10:53 <PoppaVic> meh. when the stack is an array, they make fine sense. NEEDING to use them all means they need to be opcodes or your code needs neural-surgery
17:12:25 <PoppaVic> Pro-Tip: Mute the "news" - it's always better
17:13:20 <corecode> hi
17:18:40 <rdrop-exit> Hi corecode
17:23:54 <rdrop-exit> Even then, I write most of my Forth code on the assumption that the stacks are not in addressable memory.
17:24:36 <tabemann> whereas I liberally use SP@, RP@, SP!, and RP!
17:25:06 <PoppaVic> It's an ABI issue, afaic.
17:25:13 <tabemann> e.g. both exceptions and multitasking in hashforth require those
17:26:26 <crc> dave0: no PICK or ROLL in my VM (nga, ngaro, maunga) designs
17:26:43 <rdrop-exit> On a hardware or soft-core Forth Machine SP@, RP@ and RP! might not even exist
17:28:04 <rdrop-exit> The stacks might be in a register file
17:28:36 <rdrop-exit> on the core itself, rather than in slow memory
17:29:23 <PoppaVic> rdrop-exit: that is true, and fine - in those cases you need to learn the tricks the designers offer to continue programming
17:31:06 <tabemann> of course, how it could be implemented is that the top N entries on the stack are either loaded or saved by those words from or to slow memory, and the rest of the stack exists in slow memory
17:31:25 <rdrop-exit> The trick is to assume at the Forth level that the stacks are stacks not memory, and to maintain locality of reference to the top few items.
17:31:48 --- quit: proteusguy (Ping timeout: 240 seconds)
17:31:49 <rdrop-exit> PICK and ROLL are anathema to that.
17:32:31 <tabemann> always assuming hardware implementations results in things that are extremely inconvenient for ordinary software implementations, such as essentially making multitasking impossible without special hardware support
17:33:45 <tabemann> if you can't treat the stack as an array into memory, how do you have multiple tasks each with their own stack?
17:33:52 <PoppaVic> rdrop-exit: "Assume is the mother of all fuckups"
17:34:15 <PoppaVic> shit either IS or it AIN'T
17:34:35 <tabemann> to me I'm aiming at software implementations first, and hardware implementations second
17:36:24 <rdrop-exit> Like you said it depends on the hardware support
17:37:18 <john_cephalopoda> You can just have one stack for the kernel and separate stacks (in memory, pointed at by a special register). When you swap tasks, you swap out that register value.
17:38:10 <john_cephalopoda> Hardware stacks don't really work well with multiple processes.
17:38:47 <tabemann> you can load and store them to memory when you execute SP@ RP@ SP! RP!, but that incurs a performance hit
17:39:22 * PoppaVic sighs
17:42:15 <rdrop-exit> The point is regardless of the underlying implementation, the more of your code treats the stacks as stacks the better. It fits with the underlying locality of reference assumptions of a stack machine model.
17:42:47 <john_cephalopoda> When you keep them in memory constantly, then you don't have to mess with hardware stacks but you only have to move around one pointer.
17:43:58 <john_cephalopoda> Internally it can be solved in any way, but to the process it should look like there's a stack, not a memory region.
17:44:41 <rdrop-exit> Code that uses PICK and ROLL is geared to towards an underlying register machine model.
17:44:52 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth
17:44:52 --- mode: ChanServ set +v proteusguy
17:45:29 <rdrop-exit> Less PICK and ROLL in your Forth code is a good thing.
17:46:02 <corecode> hi
17:46:25 <tabemann> except it makes it hard to do anything that requires more than two items on the stack
17:46:36 <rdrop-exit> Hi again corecode
17:46:41 <tabemann> hey corecode 
17:46:55 <john_cephalopoda> Yeah, doing something on a stack that is more than 4 elements deep in a word is bad.
17:47:09 <john_cephalopoda> Uh, more than 3*
17:47:16 <corecode> yea
17:47:29 <corecode> then you might as well use variables
17:47:37 <rdrop-exit> Refactor your code
17:48:02 <corecode> my cpu cannot access anything but TOS, NOS, R@
17:50:27 <rdrop-exit> bbiab
17:56:29 <rdrop-exit> Acoording to Blaauw & Brooks the main difficulty imposed by a zero-operand architecture (i.e. stack machine) is dealing with repeated operands.
17:56:36 <rdrop-exit> * According
17:57:44 <rdrop-exit> i.e. formulas where one or more of the operands appears multiple times on the right side.
17:59:09 <rdrop-exit> In other words it's not so much that you need 3 or 4 items from the top of the stack, it's that some of those items are used multiple times in the formula.
18:03:36 <rdrop-exit> You can either deal with that problem by factoring judiciously, or by punting and using PICK/ROLL or locals.
18:06:45 <rdrop-exit> ... or dedicating a memory location (fixed or volatile).
18:17:47 <rdrop-exit> The first instinct should be to at least attempt to solve the particular problem via factoring.
18:21:31 --- quit: dave9 (Quit: dave's not here)
18:21:50 --- join: dave9 (~dave@193.060.dsl.syd.iprimus.net.au) joined #forth
18:24:33 <rdrop-exit> Hence the wisdom of Chuck's dictum: Forth is highly factored code.
18:29:25 <PoppaVic> wow, that got ugly quick ;-)
18:30:14 <rdrop-exit> :))
18:31:01 <PoppaVic> I got down the list to 2over, ok - it's verbose.. I start 2rot.. wow.. that's a shitload of juggling
18:33:22 <rdrop-exit> Which is why on a software based VM you're better off implementing it as an opcode than synthesizing it in high-level Forth.
18:34:09 <crc> what is the stack effect for 2rot?
18:34:37 <rdrop-exit> 2rot ( d1 d2 d3 -- d2 d3 d1 )
18:34:59 <rdrop-exit> where each d is two cells
18:35:09 <crc> ahh, doubles, got it
18:35:27 <corecode> isn't it >R >R 2SWAP R> R> 2SWAP
18:35:41 <PoppaVic> {2>r:>r >r} {2swap:{rot:>r swap r> swap} >r {rot:>r swap r> swap} r>} {2r>:r> r>} {2swap:{rot: >r swap r> swap} >r {rot:>r swap r> swap} r>}
18:36:25 <crc> I've never actually implemented double cell words; the only Retro that had them was R9, and that was only in the ANS compatibility layer written by Neal Bridges
18:36:29 <corecode> what's the difference between rot:>r and rot: >r
18:36:45 <rdrop-exit> Luckily 2rot is not something you need every day
18:36:48 <PoppaVic> corecode: none, just trying to track where I was c&p from
18:36:56 <corecode> ok
18:37:04 <rdrop-exit> Except maybe on a 16-bit system
18:37:08 <corecode> too many curlies for me
18:37:23 <corecode> hey, i'm thinking about making an 8 bit forth
18:37:31 <corecode> cpu*
18:37:33 <PoppaVic> corecode: just self-notation: so I could see how calls would go vs opcode "native"
18:38:32 <PoppaVic> crc: it's one of Those Things where you think "optional, extension 'opcodes'"
18:38:36 <rdrop-exit> There were some 4-bit stack machines
18:38:41 <crc> The lazy & inefficient solution:   :2rot 'abcdef 'cdefab reorder ;
18:38:48 <PoppaVic> rdrop-exit: there is also A Lobotomy.
18:40:04 <rdrop-exit> in C: re6(Z,Y,X,T,Q,P);
18:41:25 <rdrop-exit> i.e. reassign top 6 stack entries
18:43:53 <rdrop-exit> https://en.wikichip.org/w/images/5/54/MARC4_4-bit_Microcontrollers_Programmer%27s_Guide_%281994%29.pdf
18:47:21 <corecode> fanc
18:47:26 <corecode> the x and y registers
19:00:51 <rdrop-exit> IIRC there were some papers by the designer of the MARC4 in some of the FORML proceedings
19:02:48 <rdrop-exit> The HP Saturn CPU used in some calculators was also 4-bit
19:03:55 <rdrop-exit> https://en.wikipedia.org/wiki/HP_Saturn
19:09:42 <ttmrichter> 4-bit cores are hidden in many places.
19:09:55 <ttmrichter> Only the truly "fortunate" actually tend to program them, though.  :D
19:10:08 <rdrop-exit> :))
19:10:16 <PoppaVic> If I was really "lucky" I could be blind, too
19:10:44 <ttmrichter> I'm pretty sure, for example, that most MCU peripherals like various timers, comms components, etc. are implemented in-silicon with 4-bit cores and microprogramming.
19:11:07 <rdrop-exit> Nice braille keyboard you have there PoppaVic.
19:11:23 <corecode> ttmrichter: wa?
19:11:42 <ttmrichter> I can't conceive of a gate-level only way to make an STM32 TIM1 or TIM8 timer, for example, that wouldn't be horribly terrible, but it would be trivial to write a 4-bit microprogram for.
19:12:03 <PoppaVic> rdrop-exit: I'd rather be dead - and the gods keep screwing me on that, too
19:12:04 <rdrop-exit> https://en.wikipedia.org/wiki/4-bit
19:12:24 <corecode> why couldn't you do it with gates?
19:12:54 <ttmrichter> I didn't say you couldn't.  I said I can't conceive of anybody actually doing it over embedding a 4-bit core.
19:13:08 <ttmrichter> I mean since the 4-bit core is made with gates...
19:13:36 <PoppaVic> hm.. my gates are usually made of steel - or wood.
19:13:38 <ttmrichter> But some of the logic in a TIM1 is pretty hairy and programming that logic in at the gate level would be ... unpleasant.
19:13:50 --- quit: dddddd (Remote host closed the connection)
19:14:20 <ttmrichter> Also, reading the errata sheets for these things, a lot of the bugs reported sound like programming errors too.  :D
19:22:20 <rdrop-exit> Catch you all later, keep on Forthin'
19:22:30 --- quit: rdrop-exit (Quit: Lost terminal)
19:24:55 --- join: darithorn (~darithorn@75.174.231.56) joined #forth
19:36:20 <PoppaVic> well, nowdays the silicon is chinee - and the docs might as well be. I dunno how chingrish exposes much of anything
19:48:24 --- quit: darithorn (Quit: Leaving)
19:48:49 <ttmrichter> PoppaVic: Could you translate that into something a bit more coherent and English-like?  :D
19:53:56 <PoppaVic> ttmrichter: no.
19:54:04 <PoppaVic> ..and neither can they
19:56:48 <dave0> : 2swap 3 roll 3 roll ; : 2rot 5 roll 5 roll ;
19:57:08 <PoppaVic> bad llama
19:57:16 <dave0> you gotta admit that's pretty tidy
19:57:25 <PoppaVic> I've done such before.
19:57:46 <PoppaVic> ..iirc, I felt it was "clever"
20:01:10 <crc> :2swap (d1d2-d2d1)  'abcd 'cdab reorder ;
20:02:15 <dave0> back in 1/2 hour
20:06:36 <PoppaVic> crc: that's handy in assembler-hell ;-)
20:37:21 * crc works on a postmortem look back at Retro 11
20:45:44 --- join: gravicappa (~gravicapp@h109-187-44-245.dyn.bashtel.ru) joined #forth
20:50:09 <dave0> does everyone do the words   2>r 2r> 2r@ r@    as primitives? i have for example : r@ r> dup >r ; which is very elegant, but it doesn't work because the pushed IP get in the way. : r@ r> r> dup >r swap >r ; works but it's far less elegant... is there any other way besides making them primitives?
20:50:52 <PoppaVic> extra pop and push of the return address
20:51:15 <crc> dave0: I don't have any of those in mine
20:52:03 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
20:52:35 <dave0> crc: how do you access the return stack?
20:52:37 --- join: learning (~learning@4.35.154.131) joined #forth
20:52:37 --- quit: learning (Remote host closed the connection)
20:52:46 --- join: learning (~learning@4.35.154.131) joined #forth
20:53:01 <dave0> PoppaVic: yeah but the code gets very complicated :-(
20:53:01 <crc> pop (same as r> ) and push (same as >r )
20:53:18 <rdrop-exit> dave0 You could define them as inlined words
20:53:25 <dave0> rdrop-exit: oh!
20:53:48 <dave0> that's interesting
20:55:02 <dave0> 2>r 2r> 2r@ r@ are only 3 words apiece.. inline would work dandy
20:55:26 <rdrop-exit> : r@ ( -- x )( r: x -- x ) r> dup >r ;inlined compiled
20:55:28 <crc> dave0: it's a stack, I can't do deep operations on it.
20:56:16 <crc> the stack primitives I use:  lit, dup, drop, swap, push, pop
20:56:48 <crc> nothing touches more than TOS and NOS on the data stack, or TORS on the return stack
20:57:23 <dave0> crc: do you do eg. rot in terms of those primitives?
20:57:39 <rdrop-exit> Or you just implement it as a primitive instead
20:57:57 <crc> dave0: yes
20:58:32 <dave0> thanks everyone
20:58:49 <crc> :rot  (abc-bca)   [ swap ] dip swap ;  or  :rot (abc-bca) as{ 'puswposw i }as ;
20:58:58 <rdrop-exit> :)
20:59:24 <crc> (where `[ ... ] dip` is basically `>r ... r>`)
21:01:08 <crc> (the second one is using inline assembly for my vm, assembling an instruction bundle of `push/swap/pop/swap`)
21:02:31 <dave0> oh "as{" for assembler
21:02:53 <crc> yes
21:03:21 <dave0> back in 10 mins
21:04:10 <crc> `i` takes a string representing the instruction bundle and inlines the appropriate machine code, `as{` turns off the compiler, `}as` turns it back on 
21:04:24 <rdrop-exit> In my case ";inlined" says it the world will be inlined, and "compiled" says the word is for compile-time usage.
21:04:40 <rdrop-exit> *word not "world" :))
21:11:41 <crc> I have a word class that can inline a definition if it's a single instruction bundle long. Doing longer is possible, but I don't track word length, and all addressess are absolute, which complicates things if the word is using conditionals.
21:22:27 --- quit: learning ()
21:27:35 --- quit: pierpal (Quit: Poof)
21:27:52 --- join: pierpal (~pierpal@host171-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
21:31:45 <ttmrichter> rdrop-exit: I like that design.  Consider it yoinked.
21:32:04 <rdrop-exit> ok :)
22:06:40 --- quit: gravicappa (Ping timeout: 245 seconds)
22:16:22 --- join: gravicappa (~gravicapp@h109-187-235-217.dyn.bashtel.ru) joined #forth
22:50:52 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:52:17 --- join: [2]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:53:41 --- quit: MrMobius (Ping timeout: 246 seconds)
22:53:46 --- join: [3]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:55:06 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:55:18 --- quit: [1]MrMobius (Ping timeout: 240 seconds)
22:56:40 --- quit: [2]MrMobius (Ping timeout: 245 seconds)
22:58:18 --- quit: [3]MrMobius (Ping timeout: 240 seconds)
23:09:14 --- quit: rdrop-exit (Quit: Lost terminal)
23:50:50 --- quit: proteusguy (Remote host closed the connection)
23:52:01 --- quit: dys (Ping timeout: 246 seconds)
23:59:59 --- log: ended forth/19.01.30