00:00:00 --- log: started forth/14.02.17 00:38:21 --- join: itsy (~digital_w@87.114.114.212) joined #forth 01:08:49 --- join: true-grue (~quassel@95-25-114-13.broadband.corbina.ru) joined #forth 01:47:14 --- quit: mnemnion (Remote host closed the connection) 01:52:47 --- quit: c00kiemon5ter (Remote host closed the connection) 02:37:24 --- quit: kludge` (Ping timeout: 245 seconds) 02:40:44 --- join: kludge` (~comet@unaffiliated/espiral) joined #forth 03:03:43 --- join: c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) joined #forth 03:24:28 --- join: pvt_petey (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 03:28:23 --- join: fantazo (~fantazo@213.129.230.10) joined #forth 03:46:39 --- join: Bahman (~Bahman@2.178.162.27) joined #forth 03:55:20 --- quit: Bahman (Quit: Leaving.) 04:05:03 --- join: Bahman (~Bahman@2.178.162.27) joined #forth 04:05:04 --- quit: Bahman (Client Quit) 04:09:41 --- join: Bahman (~Bahman@2.178.162.27) joined #forth 04:21:24 --- quit: tangentstorm (Quit: WeeChat 0.3.2) 04:38:42 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 04:39:36 --- quit: Zarutian (Client Quit) 04:40:59 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 05:03:30 --- join: pvt_pete_ (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 05:04:07 --- quit: pvt_petey (Ping timeout: 265 seconds) 05:37:32 --- quit: Bahman (Read error: Connection reset by peer) 06:17:00 --- quit: ASau` (Ping timeout: 265 seconds) 06:23:13 --- quit: pvt_pete_ () 06:23:51 --- join: ASau` (~user@p5083D5D8.dip0.t-ipconnect.de) joined #forth 06:27:38 --- quit: drobban (Read error: Operation timed out) 06:29:48 --- quit: ttmrichter (Read error: Operation timed out) 06:30:08 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 06:30:40 --- join: ttmrichter (~ttmrichte@192.241.205.8) joined #forth 06:32:57 --- join: drobban (~drobban@78-73-61-250-no187.tbcn.telia.com) joined #forth 06:37:20 --- join: kumul (~mool@66-50-66-157.prtc.net) joined #forth 06:39:26 --- join: pvt_petey (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 06:58:06 --- quit: pvt_petey (Ping timeout: 260 seconds) 07:00:23 --- join: pvt_petey (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 07:24:47 --- quit: Zarutian (Quit: Zarutian) 07:34:46 --- join: Fare (~fare@cpe-72-229-109-116.nyc.res.rr.com) joined #forth 07:53:56 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 07:59:27 --- join: nighty^ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 08:23:00 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 08:32:32 --- quit: kumul (Ping timeout: 245 seconds) 08:33:13 --- join: kumul (~mool@adsl-64-237-226-47.prtc.net) joined #forth 09:07:37 --- quit: kumul (Ping timeout: 245 seconds) 09:09:25 --- join: bbloom (~bbloom@cpe-68-173-7-82.nyc.res.rr.com) joined #forth 09:41:44 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 09:43:03 --- quit: bbloom (Ping timeout: 260 seconds) 10:37:04 --- join: pvt_pete_ (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 10:37:12 --- quit: pvt_petey (Ping timeout: 264 seconds) 10:59:29 --- join: bbloom (~bbloom@cpe-68-173-7-82.nyc.res.rr.com) joined #forth 11:01:38 --- quit: nighty^_ (Ping timeout: 248 seconds) 11:06:24 --- join: aranhoide_ (~aranhoide@69.Red-83-57-126.dynamicIP.rima-tde.net) joined #forth 11:10:36 --- join: nighty^_ (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 11:26:19 --- quit: carc (Quit: QUIT) 11:27:01 --- join: carc (~carc@unaffiliated/carc) joined #forth 11:42:09 --- quit: aranhoide_ (Ping timeout: 260 seconds) 11:49:41 --- join: kc5tja (~sfalvo@166.78.62.138) joined #forth 11:49:41 --- mode: ChanServ set +v kc5tja 11:49:43 --- join: b_jonas (~x@russell2.math.bme.hu) joined #forth 11:50:44 So, on the issue of task switching, the MISC architectures created so far do not have interrupts, so preemptive multitasking can't occur. 11:51:19 However, you can always preserve the carry by: DUP N RSHIFT, where N is the word width of the CPU. 11:51:38 It's a bit slow, but if it's needed, it's at least an available option. 11:52:19 kc5tja: do you really consider this a forth machine though, even with so few registers? 11:52:47 Well, the Kestrel's current hardware isn't a true Forth architecture, but it's surprisingly adept at running it. 11:52:57 The next CPU design will be a true Forth CPU. 11:53:07 You do bring up an interesting issue though: what to do with all those carry bits. 11:53:17 kc5tja: I mean, when you translate forth to it, don't you typically end up saving everything to memory at every point, at which point it's as good at forth as a register machine? 11:53:23 Maybe expose them as a special-purpose register that the CPU can read? 11:53:44 b_jonas: On the 16-bit CPU, yes. Not on the 64-bit CPU design. 11:53:59 The 64-bit CPU will have 17-deep data stack, and 17-deep return stack on-chip. 11:54:34 kc5tja: I'm not really the right person to ask about this, both beacuse I don't understand much of the hardware part so I don't know what costs what amount, and because this is your cpu so you have to do the design tradeoffs, 11:54:35 That might not seem like much, but unless you write deeply recursive code, it's usually considered "more than enough" for just about any application. 11:55:13 Well, it's just that your question about the carry bits not fitting into memory raised an interesting issue I'd not considered before. 11:55:35 Because, if I port Plan 9 over to it (something I'd like to do some day), that IS a preemptively multitasking system, and that MUST deal with those carry bits somehow. 11:55:40 but I'd say at least consider not adding extra carry flags, but instead add an unsigned compare that puts the compare result right to the stack 11:55:47 If I can solve that issue before I write the first line of Verilog, all the better. :) 11:55:50 and possibly a signed compare too, but that's less important 11:56:11 --- quit: fantazo (Ping timeout: 245 seconds) 11:56:24 The carry bits have to be there for other reasons (multi-precision arithmetic, and it's used by the multiply-step instruction). 11:56:48 Doggone it -- I have to attend a meeting in five minutes. 11:56:52 channel: for context, kc5tja is designing a minimalistic computer, some plans described at http://sam-falvo.github.io/kestrel/ , we're talking about its cpu 11:57:44 Yes folks, after several years of pontificating about it, the Kestrel lives. :) 11:57:55 (I used to sit in this channel religiously back some years ago.) 11:58:33 kc5tja: as for the stack, are you planning to do a stack that tracks the stack size and when the stack overflows it raises a fault (or a trap when it gets close to overflow) and in the handler for that fault you spill the bottom half of the stack to ram, and similarly for a stack underflow (or near underflow) you retrieve the bottom of the stack from ram? 11:58:52 this at least in user mode, not necessarily in system mode 11:59:34 of course, that might be a bit slow if you only have 17 elements on the stack, it might get more practical if you have like 32 12:00:02 Not at this time. If it falls off the stack, it falls off. The ABI will be such that at least three stack elements are to be reserved for system software use, which is enough to flush the stack out to memory. 12:00:56 Two minutes. I gotta go. I'll be back in about an hour-ish, worst-case. Maybe two, since it's close to lunch time. 12:00:58 --- quit: Zarutian (Quit: Zarutian) 12:31:45 --- quit: pvt_pete_ (Ping timeout: 264 seconds) 12:33:35 --- join: pvt_petey (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 12:41:07 --- quit: mark4 (Remote host closed the connection) 12:41:26 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 12:52:27 back 12:53:04 hi 12:57:41 --- quit: true-grue (Read error: Connection reset by peer) 12:59:04 kc5tja: so do you have any plans for this 64 bit thing written down? 13:02:48 kc5tja: or about the status of how much of the 16 bit variant works 13:26:47 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 13:28:46 Well, the 16-bit CPU is done, in that I use every feature that it supports currently. 13:29:24 The 64-bit design is not yet spec'ed out yet. That will take me some time, which I'll probably start hacking on and off after MakerFaire this year. 13:30:25 do you use banked memory with the 16-bit cpu? or you really use only 32768 bytes of memory, including memory-mapped stuff? 13:31:41 (it's just that I'm young and I don't think 32kb is enough for anything) 13:31:50 A grand total of 48KB of RAM is presently configured with the CPU; 16KB is hard-wired to the MGIA for video display, and the rest is for the CPU to use as it wants. 13:32:17 Hehe, well, if I had a better instruction density, I'd be able to do everything I need in 16KB. :) 13:32:30 but is that banked somehow? didn't you say you had only 15 bits of address space? 13:32:47 Home computers back in the day originally shipped with as little as 4KB. There's even a programming language that fits in something like 768 bytes called VTL-2. 13:32:50 No. 13:32:52 That's flat memory. 13:33:01 sure, I know 13:33:36 I know that much of history, and I know how the atari console has 128 bytes of ram and 4K of rom and how tricky its specifically designed video card is, 13:33:45 The 15-bit thing was when we were talking about comparing numbers. Most of my quantities are (signed or unsigned) less than 15 bits wide. 13:33:47 but just because I know all this doesn't mean I really believe in it 13:33:59 but... you need addresses 13:34:07 Yes. 13:34:20 ok, so 16 bit address space, not banked 13:34:26 Correct. 13:34:42 but wait, don't you have other memory-mapped devices? 13:34:45 I have RAM mapped from $0000 to $7FFF, and again from $C000 to $FFFF (this is the video RAM). 13:34:55 I/O devices are mapped from $B000-$BFFF. 13:35:26 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #forth 13:35:44 16KB for io devices of which 16KB is the video display? how does that work? 13:36:25 4KB for I/O (of which I'm only really using a few bytes), 16KB for video memory, plus 32KB for RAM equals 52KB. 13:36:33 That's 12KB available for other stuff. 13:37:01 ah, so you have less than 48KB of ram. I see 13:37:17 or something 13:37:20 32KB for program memory, and 16KB for video memory. 13:37:23 probably it's too late for me to make sense of this 13:37:27 I have exactly 48KB of memory total. 13:37:32 12k should be room enough for tetris :) 13:37:39 ah, you count the video ram into the ram tally! 13:37:40 I see 13:37:54 At this level, yes. 13:38:26 In most conversations, I'll not count video memory, since it's used entirely for video data. So effectively, I'll say my Kestrel is a "32KB machine" even though it's really got 48KB installed. 13:38:49 tangentstorm: With a reasonable instruction density, I'd say yes. :) 13:39:02 My CPU has the same density as a 32-bit RISC, which is unfortunate. 13:40:48 My clone of Spike Dislike is roughly in the vicinity of 8KB though. 13:40:56 :) 13:40:58 Although, technicallly, it's not finished yet. 13:41:20 I need to make it score and kill the player, and to make the ball follow a ballistic trajectory. 13:41:20 kc5tja: these kinds of things are rarely finished 13:42:44 kc5tja: but yes, 32kb of ram (without extra rom) should be easily enough for tetris, at least if the cpu and ram is fast enough to do everything every inefficiently 13:43:35 For _most_ operations, the CPU is, despite its lack of instruction diversity, about as fast as a 6502 at similar clock speeds. 13:43:57 Some things the 6502 is faster, and other things, the S16X4 is faster. All in all, though, it averages out to be quite competitive. 13:44:10 right 13:44:17 To be fair, I didn't _design_ it to be that fast, it just happened to fall out of the design. :) 13:44:19 and how fast is it really? 13:44:27 I do long for the 6502's or Z-80's instruction density though. 13:44:44 Right now, it is running at 25MHz with 1 wait state every other clock, so about 12.5 MIPS. 13:45:16 In my current FPGA chip, it's capable of running around 120MHz with optimized path to memory. 13:45:22 that's fast enough 13:45:26 (At least, that's what the synthesis tool tells me) 13:45:35 how fast can it write the video ram? 13:45:49 25MBps 13:46:02 really? wow 13:46:05 burst speed, of course. Instruction fetching intervenes. 13:46:16 Yeah, nice thing about the block RAMs in the FPGA -- they're dual ported. ;-) 13:46:20 ah 13:46:22 nice 13:46:25 so all the ram is in the fpga? 13:46:35 Yep, that's why there's so little of it. 13:46:46 I see 13:46:54 Honestly, I only intended the S16X4 to serve as a debugging aid while I built out the rest of the computer. 13:46:58 I thought you had so little of it because you didn't want to mess with banking 13:47:03 I never intended it to be "the" core of the Kestrel-2 design. 13:47:09 hehe! 13:47:12 Yet another one of those things that just happened. :) 13:47:19 But, soon, it'll be time to move on. 13:47:52 Right now, though, my priority is to get the computer with a working Forth system first. After that's done, then I spec out the eP64. 13:48:27 I see 13:48:56 So, my goal is to get Forth running first, then implement a 64-bit crippled CPU which is capable of accessing RAM along with the S16X4 CPU. This will slow things down, but at least I'll have a debugging terminal to hack on the 64-bit CPU with. 13:49:27 Once that's up to speed, I add support for external RAM (which gives me 8MB on my FPGA board), using software-managed cache lines. 13:49:56 Once that's debugged and I have a working 64-bit Forth for it, I'll shed the 16-bit CPU. 13:49:58 "software-managed cache lines"? wtf 13:50:06 is that like paging from ram? 13:50:10 Then it'll be time to drive the CPU up to 65MHz. 13:50:14 paging to a fast ram from a slow ram? 13:50:17 Yep, that's exactly what it is. :) 13:50:26 sounds scary 13:50:37 Well, like all things in this computer, it's about the learning experience. 13:50:49 I have no experience at all with caching, but I do with paging hardware. 13:50:50 sure, I'm just saying 13:51:03 So I figure getting the kinks worked out in software will give me valuable clues about how hardware cache controllers work. 13:51:13 And yes, there'll be a hell of a performance hit. 13:51:27 meh, I'll just stick to these powerful PCs 13:51:30 But even so, at 65MHz, it'll still be faster than the Kestrel today. :) 13:52:03 That's fine, if you don't care about hackability on them. 13:52:09 the ones where I do computations on arrays hundred megabyte size 13:52:34 Yeah, even with the vector coprocessor I'm thinking of, you won't be working on 100+ MB vectors. 13:52:44 I can still do interesting things on a PC really. I'm just more interested in somewhat higher level stuff. I'm not a hardware guy. 13:53:30 Me too, but I'm also interested in the lower levels. Also in communication protocols and the like. 14:00:13 --- quit: daowee (Read error: Connection reset by peer) 14:00:48 kc5tja, have you seen the videos about the mill architecture? 14:01:10 in some ways the opposite of MISC, in other ways the same thing 14:02:11 Fare: Yes! VERY interesting! And I love Godard's presentation style too. Very clear yet very concise. (Well, usually.) 14:02:38 --- join: aranhoide (~aranhoide@69.Red-83-57-126.dynamicIP.rima-tde.net) joined #forth 14:02:53 so you're having a 64-bit Forth-like CPU in FPGA? 14:02:56 I've often considered the use of a TTA for the Kestrel's CPU (I may yet try it after the 64-bit MISC is in place), but the Mill concept seems much more interesting to me now. 14:03:05 TTA? 14:03:16 Yep. Dr. Ting gave me permission to take the eP32 and widen it to 64 bits, and release it under Apache license. 14:03:26 Transport-Triggered Architecture. 14:03:27 nice 14:05:27 I just got a crude Forth VM working last night for the 16-bit CPU implementation. I hope to have a working Forth environment by MakerFaire. 14:05:37 I'd like to see memory chips with integrated forth cpu :-) to each chip, its processor. That would be massively parallel. Not sure what the best interconnect architecture, but that can be figured out later. 14:05:38 Speaking of which, I still need to send in my paperwork. 14:05:55 will you be at HOPE X ? 14:06:16 Not familiar with it. I'll be at the San Mateo Maker Faire though, in the SVFIG booth. 14:08:22 Ahh, a conference. Unfortunately not. Not enough vacation time. Maybe next year? 14:08:32 Wife permitting, of course. :) 14:08:51 HOPE has a makerfaire aspect to it, but other ocean cost 14:08:58 hope.net 14:09:02 coast 14:09:06 cost, too 14:09:49 it's not every year, but there will be a HOPE XI 14:12:06 I'll definitely read up more about it. 14:12:31 Might be a good excuse to come out and hook up with my parents, and take a road trip in their RV. :) 14:12:54 My family is in NY state, and this is in PA, so it shouldn't be that burdensome of a drive. 14:13:15 Sorry, I'm blind. 14:13:22 NYC, not PA. "Hotel" Pennsylvania. 14:13:31 That's even closer yet. 14:40:44 same location everytime (not every year) 15:04:19 --- join: kumul (~mool@66-50-66-157.prtc.net) joined #forth 15:06:21 --- quit: mnemnion (Remote host closed the connection) 15:18:10 --- quit: Fare (Ping timeout: 252 seconds) 15:30:15 --- quit: pvt_petey (Ping timeout: 252 seconds) 15:34:39 --- join: pvt_petey (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 15:54:09 --- join: Fare (~fare@cpe-72-229-109-116.nyc.res.rr.com) joined #forth 16:02:20 --- join: ASau`` (~user@p54AFF586.dip0.t-ipconnect.de) joined #forth 16:05:26 --- quit: ASau` (Ping timeout: 252 seconds) 16:05:29 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 16:08:19 --- quit: Fare (Ping timeout: 260 seconds) 16:11:14 --- quit: aranhoide (Ping timeout: 264 seconds) 16:18:09 --- quit: pvt_petey (Quit: Computer has gone to sleep.) 17:23:30 --- quit: Zarutian (Quit: Zarutian) 17:36:19 --- join: pvt_petey (~pvt_petey@88-107-51-20.dynamic.dsl.as9105.com) joined #forth 17:37:53 --- quit: pvt_petey (Client Quit) 20:00:07 --- nick: ASau`` -> ASau 20:54:18 --- join: Bahman (~Bahman@46.209.222.130) joined #forth 21:52:11 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 22:19:47 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 22:28:50 --- quit: kumul (Read error: Connection reset by peer) 23:59:59 --- log: ended forth/14.02.17