00:00:00 --- log: started forth/19.02.01
00:21:51 --- join: pierpal (~pierpal@host1-142-dynamic.116-80-r.retail.telecomitalia.it) joined #forth
02:03:47 --- quit: ashirase (Ping timeout: 252 seconds)
02:34:03 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
03:02:46 --- join: Montgomery (7da1896d@gateway/web/freenode/ip.125.161.137.109) joined #forth
03:03:06 <Montgomery> Hi everyone :)
03:21:01 --- quit: Montgomery (Ping timeout: 256 seconds)
03:57:12 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
03:58:14 <dave0> nite all
03:58:35 --- quit: dave0 (Quit: dave's not here)
03:59:43 --- quit: MrMobius (Ping timeout: 246 seconds)
03:59:43 --- nick: [1]MrMobius -> MrMobius
04:23:02 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:46:48 <WilhelmVonWeiner> I need a one-handed keyboard
04:47:48 <WilhelmVonWeiner> this trackball is awesome
04:48:00 <corecode> hehe
04:48:11 <corecode> one handed dvorak?
04:59:11 <WilhelmVonWeiner> I was thinking more, something chorded
04:59:31 <WilhelmVonWeiner> I made one in college out of switches, arduino and carboard
04:59:37 <WilhelmVonWeiner> might just do that again 
05:17:08 --- quit: pierpal (Quit: Poof)
05:17:27 --- join: pierpal (~pierpal@host1-142-dynamic.116-80-r.retail.telecomitalia.it) joined #forth
05:34:25 --- join: john_metcalf (~digital_w@host86-172-212-236.range86-172.btcentralplus.com) joined #forth
06:27:45 <Kumool> someone once mentioned this https://software-lab.de/penti.html here, its only for android though... actually I think it was you that mentioned it
06:38:58 * Zarutian is slowly getting his Forth VM, written in C working with all the interfaces he wants
06:52:42 <rdrop-exit> Kudos Zarutian
06:55:47 <Zarutian> just got directory listing traversal working.
06:58:59 --- quit: cantstanya (Remote host closed the connection)
07:01:56 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
07:07:25 --- quit: nighty- (Quit: Disappears in a puff of smoke)
07:39:16 --- quit: tabemann (Ping timeout: 268 seconds)
07:58:12 --- quit: PoppaVic (Remote host closed the connection)
08:18:52 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
08:50:20 --- join: darithorn (~darithorn@75.174.231.56) joined #forth
09:00:27 --- join: MickyW (~MickyW@p4FE8C395.dip0.t-ipconnect.de) joined #forth
09:03:07 <WilhelmVonWeiner> Kumool: I remember that coming up once, don't think it was I
09:16:02 --- quit: MickyW (Quit: Leaving. Have a nice time.)
09:16:14 --- quit: pierpal (Quit: Poof)
09:16:32 --- join: pierpal (~pierpal@host1-142-dynamic.116-80-r.retail.telecomitalia.it) joined #forth
09:39:55 <Kumool> maybe you can use your android phone to ssh into your machine?
09:40:29 <WilhelmVonWeiner> android screens aren't the most ergonomic nor tactile. I'm going to draw up a plate over the weekend
10:35:09 --- quit: rdrop-exit (Quit: Lost terminal)
10:41:55 --- join: aebkop (~tehidiot@cpc106046-hudd13-2-0-cust140.4-1.cable.virginm.net) joined #forth
12:14:48 --- quit: gravicappa (Ping timeout: 240 seconds)
13:32:49 --- quit: xek (Ping timeout: 240 seconds)
13:53:41 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
13:54:17 <dave0> hi
13:54:19 --- quit: aebkop (Read error: Connection reset by peer)
13:57:35 --- quit: Croran (Quit: No Ping reply in 180 seconds.)
13:58:50 --- join: Croran (~quassel@2601:601:1801:6dde::4276) joined #forth
14:04:22 * Zarutian just wtfs! Apearantly passing doing gcc runtime.c -o zeForth is not the same as doing gcc -o zeForth runtime.c
14:07:00 <rain1> yikes
14:07:05 <rain1> how do they differ
14:07:30 <Zarutian> well the former makes an segfaulting executable. It segfaults even before main() ever runs
14:07:32 <dave0> Zarutian: hmm it shouldn't matter?
14:08:02 <dave0> oh
14:08:55 <Zarutian> anyway, the main reason why I am just doing this single source file executable is to run my zeForth VM code
14:09:08 <Zarutian> exactly because of stupidity like this
16:48:18 --- quit: pierpal (Ping timeout: 240 seconds)
16:50:52 --- quit: Zarutian (Read error: Connection reset by peer)
16:51:22 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
16:56:38 --- join: pierpal (~pierpal@host1-142-dynamic.116-80-r.retail.telecomitalia.it) joined #forth
16:58:25 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
17:00:50 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
17:02:54 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:09:26 <pointfree> Kumool, WilhelmVonWeiner: It was me https://x0r.be/@pointfree/100789199205467782 ...and I still need to get a good 6 button mouse.
17:31:46 <rdrop-exit> I used to use a Razer Naga Hex for entering directions on hexmap games. Razer's are kinda junky, but the button layout was convenient for that purpose.
17:32:42 <rdrop-exit> Good morning Forthlings :)
18:39:36 --- join: tabemann (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
18:54:36 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
18:56:35 <corecode> hm, so my ! cannot remove 2 items from the stack
18:56:44 <corecode> so i'll call it !' or so
18:57:04 <corecode> now, should i just pop the address, and keep the value
18:57:23 <corecode> or should i drop the value, and keep the address
18:57:39 --- quit: MrMobius (Ping timeout: 272 seconds)
18:57:39 --- nick: [1]MrMobius -> MrMobius
19:03:17 <tabemann> it's pretty limiting if you cannot remove to values from the stack
19:03:24 <tabemann> two*
19:03:42 <rdrop-exit> There's !+ ( x a -- a' )
19:04:11 <rdrop-exit> where a' is a incremented by the cell size
19:04:17 <corecode> yea, i can't do that
19:04:25 <corecode> tabemann: why?
19:04:41 <corecode> only one word (@) that does that
19:05:19 <tabemann> there's plenty of words that consume more than one argument on the stack
19:05:49 <corecode> yea, but they are usually defined as thread
19:05:55 <corecode> and are not primitives
19:06:14 <tabemann> why can't you consume more than one argument? I'd consider that a bug
19:06:22 <corecode> because i can't
19:06:31 <tabemann> why?
19:06:35 <corecode> i would have to fetch two memory locations at once
19:06:38 <PoppaVic> it's like tacos - just eat 'em one after the other.. *burp*
19:06:53 <tabemann> are you doing a hardware implementation?
19:06:56 <corecode> yes
19:06:59 <corecode> my second one
19:07:10 <PoppaVic> doesn't that imply an "accumulator"?
19:07:29 <corecode> TOS is sort of the accumulator
19:07:50 <tabemann> then keep the top two elements on the stack in registers
19:07:58 <corecode> not worth it
19:08:13 <corecode> increases the size of the design
19:08:15 <corecode> i think
19:08:35 <corecode> but maybe not - i'll investigate later
19:08:59 <corecode> at the moment, i can only change the stack by one per cycle
19:09:02 <PoppaVic> if you can't manage that, logic and math is gonna' blow.
19:09:09 <tabemann> yeah
19:09:10 <corecode> why?
19:09:28 <tabemann> + - * / = <> < > all consume two arguments
19:09:29 <PoppaVic> because most of it deals in 2 ops
19:09:34 <corecode> no, they consume one
19:09:39 <tabemann> no, they consume two
19:09:41 <rdrop-exit>                   +----------------+
19:09:41 <rdrop-exit>  ------ clk    -->|      CPU       |-- t ----W-->
19:09:41 <rdrop-exit>  -3---- ds_cmd -->|   Data Stack   |-- x ----W-->
19:09:41 <rdrop-exit>  -W---- t_nxt  -->|                |-- y ----W-->
19:09:41 <rdrop-exit>  -W---- x_nxt  -->|                |
19:09:43 <rdrop-exit>                   |   dstack.sv    |
19:09:46 <rdrop-exit>                   +----------------+
19:09:50 <corecode> oO
19:10:08 <corecode> they produce one as well
19:10:15 <corecode> so they only remove one element
19:10:18 <corecode> and update TOS
19:10:18 <tabemann> but you're still doing two reads
19:10:23 <corecode> no i am not
19:10:29 <corecode> TOS is in a register
19:10:48 <tabemann> you have to read one memory location for an argument and you have to read another to refill the TOS
19:10:57 <PoppaVic> even if TOS is "a register", you need to pull  the 2nd op aswell, and sometimes push a result
19:11:11 <corecode> no, TOS becomes the result of the ALU op
19:11:37 <corecode> so you just need to decrease the stack by one
19:11:56 <corecode> PoppaVic: yes, you read from NOS
19:12:01 <corecode> but you can do that in the previous cycle
19:12:13 <corecode> so in the current cycle, you already have NOS data present
19:12:57 <PoppaVic> meh.. Throw more solder at it, until it sticks. Problem solved.
19:15:23 <corecode> not sure what that means
19:15:34 <corecode> i was just asking about what to do with !'
19:16:13 <rdrop-exit> Turn it into !+
19:16:22 <corecode> i can't
19:16:23 <tabemann> wait a cycle to read a new cell into the TOS
19:16:35 <rdrop-exit> Then you have bigger problems
19:16:43 <corecode> why?
19:17:02 <corecode> !+ would need another adder
19:17:08 <corecode> or another mux
19:17:25 <tabemann> is it necessary to do everything in a single cycle?
19:17:35 <corecode> no, but it simplifies things immensely
19:18:02 <corecode> i can just do : ! POSTPONE !' POSTPONE DROP ; IMMEDIATE
19:18:04 <tabemann> it's premature optimization
19:18:05 <rdrop-exit> If you want single cycle then your stacks should be register files not RAM
19:18:13 <corecode> tabemann: no
19:18:19 <corecode> rdrop-exit: why?
19:18:23 <tabemann> and I agree with rdrop-exit 
19:18:37 <corecode> it says 60MHz clock speed
19:18:38 <corecode> ish
19:18:43 <corecode> seems fine to me
19:18:44 <tabemann> single cycle accesses require hardware register files
19:19:02 <tabemann> RAM cannot be guaranteed to return values in a single cycle anyways
19:19:04 <corecode> no, works with with BRAM
19:19:12 <corecode> yes it can
19:19:30 <tabemann> unless you're tying your processor cycle time to the memory cycle time, which imposes signficant costs on the processor
19:19:38 <tabemann> because memory is low
19:19:40 <tabemann> *slow
19:19:53 <corecode> please check my design, it's possible i missed something
19:19:58 --- quit: dave0 (Quit: dave's not here)
19:19:59 <corecode> i just ran it in the simulator so far
19:20:54 <tabemann> you're better off using a cache with your memory and not expecting your memory to have single cycle accesses, or if you need single cycle accesses, using a hardware stack that is on die
19:21:47 <corecode> i'm using an fpga
19:22:05 <corecode> of course in an ASIC i wouldn't go to off-chip RAM for the stack
19:22:55 <tabemann> off-chip RAM is going to be slow regardless
19:22:59 <corecode> yes
19:23:01 <corecode> i agree
19:23:10 <corecode> but the FPGA has integrated BRAM
19:23:21 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
19:23:25 <tabemann> is it guaranteed to have single-cycle access times?
19:23:28 <corecode> yes
19:23:55 <corecode> some even are asynchronous and can return data in the same cycle
19:24:00 <corecode> but not on the ice40
19:24:06 <dave0> re
19:24:39 <tabemann> hey dave0 
19:24:49 <rdrop-exit> Hi dave0
19:25:11 <dave0> hi tabemann, rdrop-exit 
19:25:46 <tabemann> still, I wouldn't restrict your implementation to solely have single-cycle instructions
19:26:11 <corecode> why?
19:26:21 <tabemann> consider the divisor - that's going to be way slower than your adder - but if you insist on single-cycle instructions, all instructions will be as slow as the slowest one
19:26:32 <corecode> i don't have divide
19:26:39 <corecode> nor multiply
19:27:22 <tabemann> there is a reason why just about every architecture since the 8086 has included a multiplier and a divisor
19:27:34 <rdrop-exit> A slow single cycle design can be useful for deterministic realtime
19:27:37 <corecode> yea, they have a lot of space on the die
19:27:42 <tabemann> because implementing those things in software is damn slow, slower than any reasonable hardware implementation
19:27:48 <corecode> 60MHz doesn't feel too slow
19:28:09 <corecode> tabemann: yea i know, it's the tradeoff i'm making for this design
19:28:15 <corecode> i want this to be small
19:28:51 <corecode> but i'd love to look at some of your designs to get some ideas
19:28:54 <rdrop-exit> bbiab
19:28:59 <tabemann> being increasingly small has diminishing returns
19:29:02 <corecode> i'm just starting with cpu design
19:29:12 <tabemann> all of my designs are software ones
19:29:28 <corecode> yea the tradeoffs are different with software
19:30:22 <tabemann> I've implemented two Forths, attoforth and hashforth, with attoforth being a "big" forth that supports stuff like preemptive multitasking whereas hashforth is a comparatively smaller forth that uses cooperative multitasking
19:31:20 <tabemann> hashforth is meant to be a proof-of-concept for an #forth implementation
19:31:37 <corecode> ok
19:31:47 <tabemann> whereas attoforth was my first forth, and I was thinking way too big when I implemented it
19:32:43 <corecode> yea my implemented my first forth last month, i kept it quite small
19:33:26 <tabemann> of course attoforth has some nice features hashforth lacks, such as a readline-style line editor
19:40:34 <rdrop-exit> corecode: If you want simple on an FPGA, make it Harvard, code in on-chip ROM, data in on-chip scratchpad RAM, register file stacks.
19:41:19 <rdrop-exit> No external memory.
19:43:30 <corecode> i don't use external memory
19:43:59 <corecode> i don't have the address space for external memory :)
19:44:07 <corecode> and yes, it's a harvard architecture
19:45:04 <rdrop-exit> Basically it's an "Instant ASIC"
19:45:38 <corecode> just add silicon?
19:47:57 <rdrop-exit> Just add a ROM image when you compile the design.
19:48:04 <corecode> yea
19:48:18 <corecode> or write to iram via spi
19:54:05 <rdrop-exit> In the block diagram I posted earlier, the ds_cmd can be either replace, push, or pop. The design of a return stack can be simpler.
19:54:26 <corecode> yes, i have that too
19:54:50 <corecode> i call it dec, change, update, but i guess your names and functions are better
19:55:02 <rdrop-exit> ds_cmd is one-hot encoded
19:55:07 <corecode> yes
19:55:33 <rdrop-exit>                      +----------------+
19:55:33 <rdrop-exit>  --------- clk    -->|      CPU       |-- r ----W-->
19:55:33 <rdrop-exit>  -3------- rs_cmd -->|  Return Stack  |
19:55:33 <rdrop-exit>  -W------- r_nxt  -->|                |
19:55:33 <rdrop-exit>                      |   rstack.sv    |
19:55:35 <rdrop-exit>                      +----------------+
19:55:48 <corecode> how do you generate those diagrams?
19:56:05 <rdrop-exit> My fingers. :)
19:56:10 <corecode> ok
19:59:09 <rdrop-exit> module rstack #(
19:59:09 <rdrop-exit>  W,       // word width
19:59:09 <rdrop-exit>  RS_DEPTH // number of words in stack
19:59:09 <rdrop-exit> )
19:59:09 <rdrop-exit> (
19:59:11 <rdrop-exit>  input logic clk,           // clock
19:59:14 <rdrop-exit>  input logic [2:0] rs_cmd,  // command, one-hot encoded
19:59:16 <rdrop-exit>  input logic [W-1:0] r_nxt, // top word of return stack at next clock,
19:59:19 <rdrop-exit>                             //  N.B. r_nxt ignored if rs_cmd is pop
19:59:21 <rdrop-exit>  output logic [W-1:0] r     // top word of return stack
19:59:24 <rdrop-exit> );
19:59:41 <corecode> yea
20:02:30 <rdrop-exit> bbiab
20:07:25 <rdrop-exit> BTW, these are circular stacks, hence no overflow/underflow.
20:07:55 <corecode> well, you overflow when you put more in than what you have space for :)
20:08:24 <rdrop-exit> Yes, but you can't "physically" overflow/underflow per se.
20:09:14 <corecode> yea, that would be extra hardware to look at carry
20:09:33 <PoppaVic> I always though circular sounded like a great way to crash - too far forward or back
20:11:10 <rdrop-exit> You can't be cavalier with circular stacks, your code needs to be very carefully crafted.
20:11:39 <corecode> isn't that true for any stack?
20:11:58 <rdrop-exit> It should be.
20:14:23 <corecode> how large is your cpu?
20:15:26 <rdrop-exit> the design is parameterized, it depends.
20:15:53 <PoppaVic> well, um.. "you can't overflow" - yes, you nuke old "bottom-of-stack".. If you ever get bacj there, you get surprised. So, Not sure it gains anything.. Unless I am too tired to realize the math/indexing is cheaper?
20:16:24 <corecode> say 16 bit width, min stack size
20:17:22 <corecode> PoppaVic: wraparound stack is easier - no special signals for overflow
20:18:42 <rdrop-exit> I don't want to give out too much info, as I have a commercial use in mind. If that doesn't materialize, I'll be more forthcoming.
20:20:07 <PoppaVic> np. I've used rings for other things - it just worries me a little.
20:20:27 <corecode> i guess you won't disclose the commercial use either
20:21:02 <rdrop-exit> Not at the moment, no.
20:21:55 <rdrop-exit> Sorry :)
20:22:12 <corecode> this secrecy business is always very surprising to me
20:22:53 <corecode> either you have a valuable product, then people can't dupe you, or you don't, and you'll quickly get duped anyways
20:23:15 <rdrop-exit> Some stuff you give away, some stuff you sell.
20:23:22 <corecode> sure
20:23:38 <corecode> that's what licenses are for
20:23:49 <PoppaVic> yer posta patent the stuff - then sell it to doze or ibm ;-)
20:25:24 <rdrop-exit> If I had been fast and loose, I would have delayed my retirement by 10 or more years.
20:30:30 <PoppaVic> Retirement is fine - the lack of income sucks.
20:34:28 <rdrop-exit> My maternal grandfather died the very day of his retirement, I was 10 years old at the time, it was a major life lesson.
20:37:42 <PoppaVic> Death is certainly a Life Lesson
20:38:30 <corecode> there is a pun in there somewhere
20:38:48 <rdrop-exit> :)
20:39:06 <rdrop-exit> bbiab
20:39:13 <PoppaVic> going any further would either be rude or wrong.
20:44:21 <corecode> hm, so this new cpu design is a bit smaller, but also slower
20:46:13 --- join: gravicappa (~gravicapp@h77-94-116-79.dyn.bashtel.ru) joined #forth
22:05:20 --- quit: darithorn (Remote host closed the connection)
22:29:22 --- quit: X-Scale (Read error: Connection reset by peer)
22:33:58 --- quit: dddddd (Remote host closed the connection)
23:59:59 --- log: ended forth/19.02.01