00:00:00 --- log: started forth/14.03.20 00:26:15 morning 01:07:06 --- join: DGASAU` (~user@p54856D15.dip0.t-ipconnect.de) joined #forth 01:09:34 --- quit: DGASAU (Ping timeout: 240 seconds) 01:43:33 --- quit: ASau (Ping timeout: 240 seconds) 02:31:13 --- join: true-grue (~quassel@95-27-253-26.broadband.corbina.ru) joined #forth 02:35:50 --- nick: DGASAU` -> DGASAU 02:48:23 --- quit: ttmrichter (Quit: ZNC - http://znc.in) 02:48:55 --- join: ttmrichter (~ttmrichte@192.241.205.8) joined #forth 02:50:56 --- quit: yunfan (Ping timeout: 252 seconds) 03:02:31 --- join: drobban (~drobban@unaffiliated/robban-/x-2743946) joined #forth 03:10:07 --- join: itsy (~john_metc@30.74.125.91.dyn.plus.net) joined #forth 03:10:08 --- quit: john_metcalf (Read error: Connection reset by peer) 03:10:48 --- quit: mnemnion (Remote host closed the connection) 03:10:55 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 04:07:41 --- quit: mnemnion (Remote host closed the connection) 04:08:11 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 04:12:38 --- quit: mnemnion (Ping timeout: 240 seconds) 04:19:02 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 04:46:51 --- join: yunfan (~root@192.241.238.111) joined #forth 04:46:59 --- quit: yunfan (Changing host) 04:46:59 --- join: yunfan (~root@unaffiliated/yunfan) joined #forth 05:22:44 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 05:32:39 --- join: nighty^ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 05:55:47 re memory mapped IO continued: It also seems to me that it is easier to implement on the hardware side as the only thing needed is an address decoder that feeds into the device ChipEnable. 06:08:33 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 06:10:44 Hmmm. Well, I think that would vary from design to design. 06:11:03 But I still have a basic preference for memory mapping. 06:13:01 --- quit: mnemnion (Ping timeout: 240 seconds) 06:19:55 --- quit: Eth|cal (Read error: Connection reset by peer) 07:56:44 --- quit: Zarutian (Quit: Zarutian) 08:05:11 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 08:08:14 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 08:12:50 --- quit: mnemnion (Ping timeout: 264 seconds) 08:31:15 --- quit: impomatic (Ping timeout: 264 seconds) 09:27:46 --- join: john_metcalf (~digital_w@30.74.125.91.dyn.plus.net) joined #forth 09:40:09 --- join: kumul (~mool@adsl-64-237-226-58.prtc.net) joined #forth 10:20:53 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 10:23:20 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 11:12:05 It's actually easier to have dedicated I/O address space, since the CPU must expose a signal identifying I/O from memory accesses. This results in less logic in the address decoder for each. It also results in less fragmentation of the memory space. OTOH, yeah, memory mapping is more convenient. 11:12:10 :) 11:23:40 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 11:27:49 These days I'd most often flip an FPGA into the design and just run all the singal into it, so it would be FPGA logic that figured all of that out anyway. 11:40:03 Yeah, that's what I'm doing with the Kestrel. TDD + FPGA = quickly iterate hardware designs and have a whole lot more fun doing it. 11:51:28 Yep. 11:54:51 --- join: ASau (~user@46.114.197.110) joined #forth 11:59:17 --- join: asie (~textual@078088168214.elblag.vectranet.pl) joined #forth 12:04:01 --- join: dkordic (~danilo@93-87-179-205.dynamic.isp.telekom.rs) joined #forth 12:30:21 --- quit: Zarutian (Quit: Zarutian) 12:40:53 --- quit: nighty^ (Ping timeout: 240 seconds) 12:42:51 --- join: nighty^ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 12:43:18 --- join: nisstyre (~yourstrul@oftn/member/Nisstyre) joined #forth 12:57:52 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 13:34:13 --- quit: asie (Quit: I'll probably come back in either 20 minutes or 8 hours.) 13:53:41 kc5tja: TDD? Test Driven Developement? 14:02:55 Yep. 14:03:13 When working on the Kestrel, I alternate between TDD and Cleanroom methodologies. 14:05:54 I heard about TDD but what is cleanroom? 14:05:55 --- join: karswell` (~user@42.151.90.146.dyn.plus.net) joined #forth 14:06:45 A semiconductor cleanroom? 14:07:14 That's just a very environmentally controlled, dust free, etc. room where people can work on exposed silicon wafers without messing them up. 14:07:41 --- quit: karswell (Ping timeout: 264 seconds) 14:07:49 nono, I meant what is a Cleanroom methodology? 14:08:39 It's a software development process that is inspired by semiconductor cleanrooms. 14:09:01 In chip cleanrooms, the emphasis is on preventing dust from ruinign chips, and relying on statistical testing to improve yields. 14:09:13 Versus, just testing every chip and discarding those that don't work. 14:09:20 The latter results in more wasted effort, and wasted silicon. 14:09:24 * Zarutian never seen a cleanroom himself but has seen clean glove box used for the same process. 14:09:31 Cleanroom process is basically that same idea applied to software development. 14:09:54 Have you seen those Intel ads with the people in bunny suits working with chips? 14:11:36 seen the ads and movies where they do cleanroom stuff in cleanrooms. But I have seen the glovebox cleanroom with my own eyes. 14:12:49 Even after googling, I'm left ignorant of what that means. 14:13:12 Are these the clear plastic boxes with the gloves you stick your hands through to manipulate hazmat? 14:14:23 kc5tja: that, or stuff that has to be kept very clean 14:14:43 Ahh, OK, so I learned a new term today. 14:15:02 So, yeah, same basic idea, just applied to software. 14:15:25 In extreme implementations, software engineers don't even have access to the compilers used to write the software. (Only QA staff does.) 14:15:40 It's the core of the process behind what NASA uses to write the Shuttle's avionics too. 14:16:07 I used it with the Kestrel where testing interactively wasn't possible or more expensive (in time, etc.) than I was willing to invest. 14:17:34 so basicly you write the code with pen and paper until you are satisfied that it is correct? 14:17:53 where satisfied means is mathematically proven to be correct, yes. 14:19:31 what methodology is used in the proofs? 14:20:17 --- join: impomatic (~chatzilla@30.74.125.91.dyn.plus.net) joined #forth 14:21:42 because Knuth emptor ;-) 14:22:15 They don't specify a specific methodology for proofs, as long as it's done. Personally, I use the exact same method used in Forth -- Hoare Triples. 14:22:33 "Beware that I have prooven above code correct but have not tested it" -Knuth. 14:22:38 If you've ever seen a stack annotation comment, you've seen Hoare Triples at work. 14:23:06 Proven code is proven. No way around it. If there's a bug, it's invariably in misunderstanding the requirements. 14:23:18 I have seen and written a few of those. Why are they called Triples? 14:23:20 Proofs get a lot of unnecessary bad rap. 14:23:35 Hoare's triples are traditionally written like this: {P} S {Q} 14:23:55 where P are your preconditions, S is the statement(s) in your code, and Q are the results/post-conditions that are known to be true. 14:24:01 Hence the "triple". 14:24:10 I see. 14:24:11 In Forth, it's written : S ( P -- Q ) ... ; 14:24:26 Though, usually in much less detail. 14:25:00 The idea with HTs is just as it is in Forth -- prove the lower level words/functions correct, and you can treat them axiomatically in higher-level code. 14:25:21 Thus, you avoid the infinite regress that normally comes with more formal verification systems. 14:25:50 If you've ever heard of Design by Contract, that's the same thing by another name. 14:27:42 For problems where Cleanroom works well, I find the "black box" decomposition (a particular phase of design in Cleanroom) "state box" decompositions can yield a substantially more complete set of test cases than I'd ever come up with TDD alone. 14:28:15 These two phases basically result in a depth-first search of the input edge-case space. 14:28:38 TDD is basically an on-demand, heuristic approach towards test case coverage. 14:29:11 you have to explain those for me. What do you mean by "black box" decomposition? You decompose your target problem into black boxes and then those black boxes into more simpler black boxes? 14:29:30 Kind of. 14:30:32 Black box decomposition is a purely functional decomposition of the problem. State box is the first time you introduce state, but it's a state machine. Clear box is a further refinement, where you introduce pseudo-code or even raw programming language constructs, where invalid or inconsistent states are possible. 14:30:55 The idea is that you can always trace a program statement back to a state definition, and that to a functional decomposition, and _that_ to a user requirement etc. 14:31:11 I see. And you test each state of the state machine? 14:31:17 So, as you can see, every step of the process consists of checks and balances. 14:31:29 Yep. 14:31:36 Well, let me rephrase that. 14:31:45 Where feasiable, *I* test each state. 14:31:51 However, that's just a feel-good for me. 14:32:08 Zarutian: you're familiar with the concept of doing the simplest thing that'll make the test pass? 14:32:08 If you prove the code correct, you shouldn't ever need the tests. 14:32:22 (so far, none of my Cleanroom code has failed a single test). 14:32:24 gordonjcp: KISS Keep it small and simple 14:33:04 I use the tests more as a source of documentation than anything. 14:33:17 People ask questions on how to use the code, and I point to a test that they can run and play with. 14:33:51 so tests are pretty much your example code of how to use it? nice 14:34:09 Yep. 14:34:24 Now...that said...there are problems where Cleanroom CAN be used, but it's fairly expensive. 14:34:52 Defining an open-ended interpreter for something (say, Forth itself) is quite difficult for Cleanroom to express. Not impossible, though. 14:35:22 But, for these kinds of situations, I prefer TDD, since heuristically, it's relative lack of expense more than makes up for the possibilities of lingering bugs that may exist. 14:35:41 So for me, I don't restrict myself to just TDD or jsut to Cleanroom; rather, I use the two together, where they each make the most sense. 14:37:17 --- quit: true-grue (Read error: Connection reset by peer) 14:40:39 kc5tja: what kind of stuff do you design and make again? 14:44:07 For fun, I work on the Kestrel self-made, MISC-architecture computer design. 14:44:48 For profit, I work with Go in an enterprise-computing market. Right now, I'm developing the Gophercloud and Mailgun-go projects on Github. 14:45:13 MISC? Medium Instruction Set Computer? 14:45:17 Close. :) 14:45:19 Minimal 14:46:09 Familiar with reading CPU data sheets at all? I can show you my S16X4A datasheet. Only 14 instructions, packed 4-wide in a 16-bit word. 14:46:45 familair with data sheets, yes. 14:47:14 context sentive instructions? 14:47:38 sensitive* 14:47:47 https://github.com/sam-falvo/kestrel/blob/master/cores/S16X4A/doc/datasheet.pdf 14:47:52 Nope -- they are what they are. 14:48:02 Although, I've been thinking about adding some context-sensitivity. 14:48:23 However, I'm not too far from adding a 64-bit CPU to replace the 16-bit CPU design. 14:48:32 Current CPU isn't a true Forth CPU, but the 64-bit CPU will be. 14:49:54 * Zarutian isnt familiar with Wishbone bus. Probably some FPGA bus spec. 14:52:05 Yeah. It's not too different from a rigorously defined 6502 bus, with support for wider data paths. 15:07:55 --- quit: dkordic (Quit: Ex-Chat) 15:21:13 kc5tja: talking about CPU's what do you think of the J1 by excamera? 15:34:12 It's an excellent CPU. I originally selected it for the Kestrel. 15:34:23 I only changed because I could never keep the instruction mapping in my head. 15:35:03 the ALU instruction is a bit tricky to remember 15:35:04 In fact, James Bowman will be speaking at this week's SVFIG meeting. Can't wait to see what he's going to present. 15:35:09 Yeah. 15:35:33 And when you're looking at hex-dumps all day to figure out why "Hello" is coming out as garbage, that's the moment I decided to switch. :) 15:36:17 well, ALU instruction is ?partially? an unencoded instruction 15:36:51 (see Stack Machine the New Wave for what is meant by unencoded) 15:55:02 I have that book in dead-tree form. 15:59:38 --- join: kumool (~mool@adsl-64-237-226-58.prtc.net) joined #forth 16:01:07 --- quit: kumul (Ping timeout: 240 seconds) 17:01:18 --- join: jonasbits2 (~Thunderbi@78-73-105-79-no162.tbcn.telia.com) joined #forth 17:51:40 --- quit: pvt_petey () 18:03:45 --- quit: jonasbits2 (Quit: jonasbits2) 18:43:56 --- quit: itsy (Read error: Connection reset by peer) 18:47:28 --- join: itsy (~john_metc@30.74.125.91.dyn.plus.net) joined #forth 19:28:39 --- quit: Zarutian (Quit: Zarutian) 19:40:20 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 20:16:22 --- join: noneofmynickswor (~mool@66-50-97-135.prtc.net) joined #forth 20:20:01 --- quit: kumool (Ping timeout: 265 seconds) 20:52:24 --- join: itheon (~linux@cpc3-lutn5-0-0-cust790.9-3.cable.virginm.net) joined #forth 20:53:50 --- join: mnemnion_ (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 20:54:27 --- quit: itheon (Remote host closed the connection) 20:55:46 --- quit: mnemnion (Ping timeout: 265 seconds) 21:39:19 --- quit: Adeon (Quit: Lost terminal) 21:39:58 --- join: Adeon (~valaat@109.73.169.52) joined #forth 23:13:04 --- quit: noneofmynickswor (Quit: Leaving) 23:59:59 --- log: ended forth/14.03.20