00:00:00 --- log: started forth/18.10.23
00:03:18 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
00:13:08 --- quit: pierpal (Quit: Poof)
00:13:26 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
00:16:23 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
00:45:28 --- quit: pierpal (Read error: Connection reset by peer)
00:58:53 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
01:05:22 --- quit: dys (Ping timeout: 252 seconds)
02:24:10 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
02:24:11 --- quit: ncv (Changing host)
02:24:11 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
02:30:53 --- quit: nighty- (Quit: Disappears in a puff of smoke)
03:38:31 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
03:45:13 --- quit: pierpal (Ping timeout: 252 seconds)
04:02:22 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
04:02:28 <dave0> re
04:27:43 <KipIngram> siraben: I've implemented my frame pointer system so that I really can treat frame entries like variables.  I have <n>@ and <n>! and <n>+! and so on.
04:28:12 <KipIngram> The offset from the frame pointer is hard coded into those primitives, so they're basically same efficiency as variables.
04:28:29 <KipIngram> So that's my "local variable" methodology.
04:28:54 <KipIngram> When I write my source editor, I'm thinking I'll provide a feature within it for "labeling" the frame entries with names.
04:29:40 <KipIngram> That will require a bit of intelligence in the editor.  And the compiled code will still just use the frame access words - only the editor will have the association between the offset and  a "local name."
04:35:06 <siraben> KipIngram:  That seems like an interesting concept.
04:35:11 <siraben> KipIngram:  Good news!  My target is working again!
04:35:25 <siraben> I just needed to boot into Windows and flash the OS from there, apparently the software works better there
04:35:27 --- join: xek (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
04:37:32 <KipIngram> Oh, outstanding.
04:37:36 <KipIngram> That is good news.
04:37:56 <KipIngram> Yeah, I think it's an interesting way to go about locals.
04:38:09 <KipIngram> I like it because it doesn't involve "invading the run-time" in any way.
04:38:29 <KipIngram> At the same time, I've found just having the frame and referencing it numerically to be fairly easy coding.
04:38:46 <KipIngram> I just scratch a little note down next to me reminding me what quantity is in what slot.
04:39:23 <KipIngram> I haven't done a whole lot of coding that way, though - there are only a couple of places in my system where I have enough on the stack to need a frame.
04:39:44 <KipIngram> Generally speaking I prefer the "Forth wisdom" on just avoiding that need to begin with.
04:40:18 <KipIngram> Maybe there are better ways to do those few places so I wouldn't need that kind of access.  
04:40:28 <KipIngram> I just haven't found them yet.
04:44:46 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
04:58:09 <siraben> Right. For me, the stack is local enough.
04:58:44 --- join: wa5qjh (~quassel@175.158.225.215) joined #forth
04:58:45 --- quit: wa5qjh (Changing host)
04:58:45 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
04:58:48 <siraben> Although I wish I could do better than SWAP 1+ SWAP
05:03:05 --- quit: wa5qjh (Remote host closed the connection)
05:15:28 <zy]x[yz> >r 1+ r>
05:25:18 <KipIngram> When I first wrote those stack access words, I offset them from SP (didn't have a frame pointer).  In theory you can do anything that way.  It's just that the reference points move around and it's a pain in the ass to keep up with.
05:25:47 <KipIngram> But at that point I would have said 1++ or 2++ or 3++ etc.
05:26:11 <KipIngram> A stricter naming convention would have been <n>1+, but that wound me up with 11+ 12+ etc, and I just didn't like it.
05:26:35 <KipIngram> Maybe I should separate the numerical parameter somehow, so 1:1+
05:26:55 <KipIngram> 2:@ etc.
05:29:10 <KipIngram> And I have missed having the stack pointer access ones since switching them over.
05:29:13 <KipIngram> Maybe I should have both.
05:29:41 <KipIngram> <depth>s<word> and <depth>f<word>
05:29:52 <KipIngram> So 1s1+ to do what you're after.
05:29:59 <KipIngram> 1f1+ to increment frame item 1.
05:30:36 <KipIngram> Of course, I could just define words to took a stack or frame item # and gave me back an address, then just use the regular words.
05:30:40 <KipIngram> But that's a lot of extra code.
06:53:05 <siraben> KipIngram:  I had a moment of insight recently.
06:53:15 <siraben> My word definitions cannot exceed $C000, but my programs can
06:53:33 <siraben> Beause a program is just a list of words.
06:53:53 <siraben> So, theoretically I could come up with an alternative threading model to use at high-address space
06:54:14 <siraben> Which means I get the benefits of direct threaded being fast on my machine, but the extra space when I need it.
06:59:19 <KipIngram> Hmmm.  I can't comment on that until you propose some details.
06:59:35 <KipIngram> But right - the definitions themselves are "data" to the processor.
07:00:09 <KipIngram> When I've thought of things like this, they usually look good until I start thinking about mixing words defined in the various ways together into one definition.
07:00:29 <KipIngram> NEXT has to know what to do for each one of them, and if they have different structures NEXT has to have a way of figuring that out and dealing with it.
07:06:20 <siraben> KipIngram:  at the very bottom of my forth.asm file is the interpreter.
07:06:43 <siraben> How a program is run is that the instruction pointer points to the first word of the interpreter.
07:07:14 <siraben> But I can also embed strings, literals etc. in the word as long as it's prefaced by the proper word
07:07:51 <siraben> e.g. .dw lit, 120, dot is equivalent to "120 ."
07:07:52 <KipIngram> Right, sure.
07:08:00 <KipIngram> yes, that's pretty standard.
07:08:02 <siraben> I'm just trying to find a way to make this as much data as possible
07:08:36 <KipIngram> Well, that's exactly what indirect threading does.
07:08:38 <KipIngram> It's all data then.
07:08:40 <siraben> Inevitably there's going to be a slowdown of sorts, that much is unavoidable.
07:08:50 <siraben> Right.
07:08:54 <KipIngram> Except your primitives of course.
07:09:07 <KipIngram> I've thought at times about how to mix direct and indirect threading.
07:09:24 <KipIngram> It's fairly easy if a word is all direct or all indirect, all the way to the bottom.
07:09:42 <siraben> That might mean my programs in the high memory region (> $C000) will have to be only pointing to words defined in the low memory region.
07:09:47 <KipIngram> Including primitives that are written to support direct or indirect.
07:09:50 <KipIngram> That works fine.
07:10:00 <KipIngram> But like I said, it's mixing them that raises issues.
07:10:19 <siraben> We'll see, I'm interested to see what arise.
07:10:21 <siraben> arises*
07:10:31 <KipIngram> Absolutely - such thoughts are always worthwhile.
07:10:41 <KipIngram> Even if they lead nowhere, they polish your knowledge.
07:10:46 <siraben> And that might involve some words that can self-modify
07:10:57 <siraben> Precisely.
07:14:10 <siraben> I'll add QQ
07:14:16 <siraben> Oops
07:14:34 <siraben> I'll add some self modifying word primitives
07:15:09 <siraben> For instance SET! might change the word pointed to by the code pointer
07:15:35 <KipIngram> Interesting.  I've never gone down that road (self-modifying code).
07:15:38 <siraben> and some branching that depends on the word at the instruction pointer
07:15:45 <KipIngram> So you may find something interesting there.
07:16:12 <KipIngram> This self modification would have to happen at run-time, I suspect?
07:16:21 <siraben> Yeah, everything will still be data but choices can be made on that data and so on
07:16:26 <siraben> Yes run-time.
07:16:49 <KipIngram> I've tried to avoid any sort of time-consuming thing at run-time.
07:17:45 <siraben> Oh the modification will happen at run time
07:17:46 <siraben> But once the changes are made the code is run as normal
07:17:55 <KipIngram> My most likely approach would probably be to have the instruction cells "tell me what they were" somehow - a bit would indicate direct or indirect threaded, and NEXT would act accordingly.
07:17:57 <siraben> So, in memory, DUP + might become DUP *
07:18:06 <KipIngram> But I think that decision process would take longer than just going all indirect.
07:18:32 <KipIngram> Since it has to be in *NEXT*.
07:18:39 <KipIngram> That's sort of the most important code in the whole system.
07:19:14 <siraben> Right, and I don't want to slow down everything
07:19:57 * Zarutian butts in late into the conversation.
07:20:21 <siraben> I should explore writing applications instead of programs for my calculator. I can go larger than 8 KB
07:20:25 <Zarutian> siraben: what is the constraint that $C000 is about on your target?
07:20:26 <siraben> Because apps are loaded in pages.
07:20:36 <siraben> ^pages
07:20:46 <KipIngram> Morning Zarutian.  Always welcome.
07:20:51 <siraben> I've seen applications with sizes like 33 KB
07:21:22 <siraben> Zarutian: my target is back
07:21:44 <siraben> I just needed to flash the OS from Windows instead of Mac, apparently TI writes better connect software there.
07:21:48 <Zarutian> siraben: was it the flash chip that gave up its magic-smoke? ;-þ
07:21:56 <Zarutian> oh, I see
07:22:00 <siraben> I did an OS check and everything worked
07:22:06 <siraben> Weird
07:22:16 <siraben> Must be some bit flip
07:22:33 <siraben> A cosmic ray did it!
07:22:39 <Zarutian> happens
07:22:57 <Zarutian> or just some static or something.
07:24:32 --- quit: tabemann_ (Ping timeout: 244 seconds)
07:25:52 <siraben> Hopefully get a couple more years out of this thing
07:27:33 <siraben> Just added a SQRT primitive
07:28:03 <KipIngram> OS call for that?
07:28:07 <siraben> It's pretty cool how it just works. I don't know how I'd have implemented it.
07:28:09 * siraben copied some stuff
07:28:19 <siraben> No
07:28:40 <siraben> OS call for the floating point square root though
07:31:58 <siraben> KipIngram:  So how's NASM, do you have all the primitives there?
07:32:03 <siraben> Multiplication, division et al. ?
07:34:10 <Zarutian> siraben: I am still curious about what the $C000 restriction is about. No direct calls to words at or above that address?
07:34:43 <siraben> No execution is allowed. i.e. the system's program counter cannot exceed that.
07:34:50 <siraben> But data and be read/written
07:35:19 <siraben> Well, obviously I think the system still manages to execute code above $C000 so it must be something about interrupts?  Not sure.
07:35:36 <siraben> I'll find out eventually.
07:36:23 <siraben> https://en.wikibooks.org/wiki/TI_83_Plus_Assembly/Memory
07:36:29 <Zarutian> siraben: oh, I see. Indirect threaded code it is then or extermely small vm
07:36:31 <siraben> "Know however that PUSH and POP change the memory at $C000-$FFFF, and that you can NOT execute in this area. "
07:36:34 <KipIngram> I haven't written division yet - I've written U/MOD.
07:36:46 <KipIngram> But yes, all of those will be simple and straightforward in nasm.
07:37:25 <KipIngram> I'm not sure what that statement means.
07:37:31 <KipIngram> HOW do push and pop change that memory?
07:37:40 <KipIngram> Why would they change memory anywhere other than where SP is pointing?
07:38:14 <siraben> Not sure exactly.  It's a very forbidden area.
07:38:40 <siraben> I found a forum post which states "I would just like to remind people that making all of $C000-$FFFF executable is entirely possible. For example, see Fullrene."
07:39:22 <siraben> Curious.
07:39:28 <KipIngram> Oh, that's encouraging.
07:40:14 <siraben> It's a pretty (at least historically) active community
07:40:22 <Zarutian> siraben: how big is the Stack Pointer register? Full 16 bit?
07:40:44 <siraben> Yes.
07:41:16 <siraben> I sometimes worry too much about performance.
07:41:25 <Zarutian> probably something to do with interrupts then.
07:41:34 <siraben> I just can't help it when I'm writing assembly, though, every cycle counts.
07:41:59 <Zarutian> here is a handy guide for determining if a program is fast enough: if you do not have time to cheer it on then it is fast enough
07:42:00 <siraben> Yeah, messing with interrupts can make my program very very fast
07:42:06 <siraben> I still don't know exactly how they work, should go off and read.
07:43:01 <siraben> I thought I knew all about the Z80 there was to know, looks like no.
07:43:58 <siraben> You know, actually having a working target has reignited my motivation again :-)
07:44:20 <Zarutian> well, I was cured of such thinking when I saw piclist.com, man the knowledge on the PICs is bottom less (handy to look for some assembler routines too)
07:45:19 <siraben> What's piclist?
07:46:41 <Zarutian> it is a site that is all about Microchip's Programable Integrated Circuit Micro Controler Unit
07:47:29 <siraben> I see.
07:47:31 <KipIngram> PICs are just EVERYWHERE.
07:47:35 <siraben> Have any of you ever ran into instances when Forth was too slow, and assembly was a better option?
07:48:25 <Zarutian> KipIngram: I am switching to AVR, why? Because it can easily host a Direct Threaded Forth.
07:48:44 <Zarutian> siraben: only in hard-hard-realtime code
07:50:52 <siraben> I just learned of a new instruction; RST
07:51:11 <siraben> RST xx = Software restart to address $00xx
07:51:35 <siraben> Funny instruction.  RST 00 simulates taking batteries out
07:51:43 <KipIngram> Zarutian: That's a fine reason.
07:52:45 <siraben> Looks like the b_call "instruction" I've been using this whole time was a macro that used RST
07:53:10 --- quit: Zarutian (Read error: Connection reset by peer)
07:53:30 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
07:53:44 <siraben> Interrupts are really over my head, how is it possible to execute code when other code is being executed?
07:54:38 <KipIngram> It's not.
07:54:43 <KipIngram> Unless you have multiple cores.
07:54:57 <ecraven> siraben: you just stop executing whatever you're running now and run the interrupt code
07:54:59 <KipIngram> An interrupt... "interrupts" the running code.
07:55:12 <ecraven> then, when that interrupt code "returns", you continue where you left off
07:55:16 <KipIngram> It's just like a subroutine call being inserted, except that generally the flags register is also saved.
07:55:55 <KipIngram> And of course there's no "interaction" between the "caller" and "callee" like in a regular subroutine, because you have no idea when the interrupt is going to happen.
08:00:14 <siraben> Huh, but how can an interrupt happen when I'm running my code?
08:00:26 <ecraven> the cpu just stops running your code and starts running the interrupt code
08:00:33 <ecraven> mostly because some pin went high or low
08:01:28 <KipIngram> Right, that's exactly right.
08:01:44 <KipIngram> It can happen because the processor state machine is designed to respond to those signals.
08:01:56 <KipIngram> Normally the state machine is fetching your instructions and acting on them.
08:02:08 <KipIngram> But if it sees this other input, it goes off and does something altogether different.
08:02:42 <KipIngram> The state machine only does the normal "your code" processing if none of those signals are high.
08:02:46 <ecraven> many cpus have some sort of interrupt "vector", which is just a list of addresses where to jump when an interrupt occurs
08:03:04 <ecraven> so if you put the address of one of your functions there, it will be invoked whenever that interrupt occurs
08:03:19 <KipIngram> Right - the different signals can all cause different actions, and that's usually implemented by just varying the location the state machine looks to decide where to go execute.
08:03:25 <ecraven> "interrupt vector table" seems to be the right word
08:04:40 <KipIngram> siraben: that same state machine, when interrupts don't occur, normally just increments the program counter to get to the next instruction.
08:05:21 <KipIngram> But when it fetches the instruction, the particular bit pattern of the instruction can tell it to do something different there too - can tell it to instead fetch the next bit of your progam and use it as an address for fetching code (replace the program counter value with it).
08:05:24 <KipIngram> That's just a jump.
08:05:34 <KipIngram> But ALL of this stuff is just a state machine responding to various input signals.
08:05:48 <KipIngram> Which one it responds to and how depends on what state the machine is in.
08:08:13 <Zarutian> KipIngram: re state machine that fetches next instruction can do an subroutine call to an interrupt handler instead is exactly how I implement such functionality in ROM-logic
08:21:52 --- quit: Zarutian (Read error: Connection reset by peer)
08:22:03 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
08:29:08 <KipIngram> Cool.  siraben, this is actually very simple stuff once you know some digital logic.  The design of a processor can be "involved," but conceptually there's nothing particularly "difficult" about it.
08:29:30 <KipIngram> State machines are not the very first thing you learn in that area, but it's not far from it.
08:31:02 <siraben> Ah yes, the Z80 has an interrupt vector as well
08:31:50 <siraben> Right, there's two modes of interrupts, software and hardware
08:31:50 <siraben> http://tutorials.eeems.ca/ASMin28Days/lesson/day23.html
08:32:04 <siraben> I'll keep reading, thanks KipIngram , Zarutian , ecraven .
08:35:40 --- part: xpoqp left #forth
08:36:01 --- quit: Keshl (Read error: Connection reset by peer)
08:36:26 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
08:44:27 <KipIngram> A software interrupt is even more like a subroutine call, in that you trigger it from a specific point in your program.
08:44:37 <KipIngram> Like a hardware interrupt, it pushes the flags as well as the return address.
08:44:56 <KipIngram> Often that changes privilege too, and is how a lot of processors give access to the OS.
09:05:18 --- quit: dave0 (Quit: dave's not here)
09:42:01 <siraben> Right. It's used for key input for instance.
09:42:20 <KipIngram> Yes, or disk access or any of various other things.
09:45:38 <siraben> Stopped by an electronics store today and there were a lot of embedded devices
09:46:18 <siraben> The sellers didn't know the chip models but it'd be interesting to see if a Forth could have been implemented on that
09:55:50 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
09:59:13 --- quit: MrMobius (Ping timeout: 252 seconds)
09:59:13 --- nick: [1]MrMobius -> MrMobius
10:30:32 <ecraven> I don't think there's a processor in existence that couldn't host a forth
10:36:00 <zy]x[yz> PIC
10:43:55 <KipIngram> Yeah, I've felt like I could cram a "Forth-ish" onto a PIC, but it's not a very friendly architecture.
10:44:41 <KipIngram> The instruction set is pretty clean, though, I once spent an afternoon writing an assembler in Forth for a PIC.  Intellectual exercise only - I never used or ran anything it did, but I remember thinking it was pretty straightforward.
10:45:04 <KipIngram> When you get to design your syntax any way you want (which means you design it to be easy to make work) it's... quite helpful.
12:38:38 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
12:47:04 <pointfree> KipIngram: I'm about to write a forth for dsPIC33 because I need the ctmu. I'm not aware of any other micros that can measure time down to 5ps.
12:49:12 <KipIngram> Oh... nice.
12:49:52 <KipIngram> What are you going to measure with it?
12:50:11 <KipIngram> I'm curious about anything that requires that kind of resolution.
12:56:21 <pointfree> KipIngram: I'm using a few led's as light sensors for a kind of compressed sensing optical flow camera. I'm measuring discharge time under light exposure rather than measuring the photocurrent directly. ( http://ch00ftech.com/2011/11/16/ldds/ )
12:56:31 --- join: john_metcalf (~digital_w@host81-136-110-38.range81-136.btcentralplus.com) joined #forth
12:57:00 <pointfree> more time resolution gives the camera greater spatial resolution.
12:57:48 <pointfree> Some people are using the ctmu for tdr to measure lengths of wire.
12:59:27 <KipIngram> Cool.  I grok that one better than your first thing.
12:59:56 <KipIngram> Damn, that would measure wire length down to like 1/20 inch.
13:00:33 <KipIngram> Chuck Moore once wrote about a "one wire keyboard."
13:01:16 <KipIngram> It was just a wire folded so both ends were accessible, and them all the keys were set up so they'd short the two pieces together.
13:01:27 <KipIngram> Measure how far from the ends the short was.
13:01:31 <KipIngram> Identify the key that way.
13:01:59 <KipIngram> Treat it like a transmission line - just send a pulse into it and time it.
13:03:13 <KipIngram> Only problem I saw with it is that you could only identify the nearest key that was depressed - everything else was "hidden."
13:03:25 <KipIngram> So I don't know how he thought he was going to do shift keys.
13:05:15 <pointfree> You could compare lengths with a race condition between two delay lines.
13:05:42 <Zarutian> I heard of keyboards that are basically giant parallel in serial out shift register.
13:08:58 <pointfree> If you project a 2d lattice at a golden ratio angle onto a 1D variable resistor you get a 1D aperiodic quasicrystal on the variable resistor. Every 2D location maps to a distinguishable 1D location -- no translational symmetry and thus no keyboard ghosting.
13:11:03 <pointfree> ...and it's continuous, so this could work for touch panels.
13:11:14 <Zarutian> pointfree: can you unpack that a bit?
13:14:35 <KipIngram> Can I imagine that as a square grid of points, and I look at it at the right angle and can see every key?
13:14:46 <KipIngram> Every point, that is?
13:15:41 <KipIngram> Or, another way - if I choose the right angle I can draw a grid of parallel lines that come in from the outside, and each line hits a lattice point and doesn't touch any other points?
13:16:20 <KipIngram> Or yet another way - if I tied a string to each point in the 2D lattice, there's an angle I can hold it at such that all the strings hang down parallel and don't touch?
13:42:20 --- quit: xek (Remote host closed the connection)
14:14:49 --- join: xek (~xek@user-5-173-128-60.play-internet.pl) joined #forth
14:17:29 --- quit: xek (Remote host closed the connection)
14:42:54 --- join: wa5qjh (~quassel@175.158.225.215) joined #forth
14:42:54 --- quit: wa5qjh (Changing host)
14:42:54 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
15:05:43 --- quit: cheater (Ping timeout: 260 seconds)
15:07:57 --- join: CORDIC (~user@109-93-214-149.dynamic.isp.telekom.rs) joined #forth
15:08:18 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth
15:08:49 --- quit: DKordic (Ping timeout: 240 seconds)
15:13:09 --- quit: CORDIC (Ping timeout: 240 seconds)
16:02:11 --- join: pierpa (4f12eaf7@gateway/web/freenode/ip.79.18.234.247) joined #forth
17:11:52 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
17:12:01 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
17:12:36 <dave0> hi
17:14:46 --- join: wa5qjh (~quassel@175.158.225.215) joined #forth
17:14:46 --- quit: wa5qjh (Changing host)
17:14:46 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
17:21:51 --- quit: wa5qjh (Remote host closed the connection)
17:29:10 <KipIngram> Hi Dave.
17:30:23 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
17:30:59 <dave0> hi KipIngram 
17:31:05 <dave0> how's it going?
17:31:40 <KipIngram> Pretty good.  Been buried in work lately though - haven't done any Forth coding in weeks.  :-(
17:31:50 <KipIngram> Read a couple of interesting docs, but that's it.
17:32:16 <dave0> siraben inspired me to learn z80 assembly
17:32:46 <dave0> so i've been writing little code snippets
17:35:45 <KipIngram> Heh heh.
17:36:26 <KipIngram> Well, historical information isn't bad.  I'll be surprised if you get to use it for anything, though.  But hey, every angle you can look at programming from has to do some good.
17:36:50 <dave0> i'm happy to run it on an emulator
17:37:07 <KipIngram> I still think that disk management is the next thing I'm going to work on.
17:37:22 <KipIngram> Logical disk management - not going to do any disk controller interfacing or anything like tha tyet.
17:37:24 <KipIngram> that yet
17:37:25 <dave0> sounds difficult :-(
17:37:36 <KipIngram> The disk handling?
17:37:40 <KipIngram> I don't think it will be too bad.
17:38:00 <KipIngram> In some ways it's similar to what I'm already doing with RAM and with my symbol table - basically just a linked list structure.
17:38:41 <siraben> dave0:  What other assembly languages are you familiar with?
17:39:55 <KipIngram> I've used x86 a good bit, and long ago did quite a bit of 6809 programming.  I read thoroughly about the 68000, because I was half in love with it, but never got an opportunity to program it.
17:40:06 <dave0> siraben: i can code x86 m68k 6809 and PIC
17:40:31 <dave0> m68k had lots of registers compared to other CISC at the time
17:40:35 <KipIngram> Looks like I'm going to be tackling Cortex M4 for this little Itsy board port.
17:40:35 <siraben> I should learn x86, hm.
17:40:39 <dave0> it was comfortable
17:41:14 <dave0> siraben: my computers are all pc's so i had to eventually learn x86
17:41:26 <dave0> i don't know the newer features like vectors
17:41:34 <KipIngram> dave0: I'm really glad they added the extra regs to x86_64; I couldn't do some of the things I'm doing otherwise.
17:41:40 <KipIngram> Me either.
17:41:44 <siraben> x86 has a lot of nice instructions, right?  Compared to the minimalism of the Z80.
17:42:14 <KipIngram> It's a monstrosity.  Which is a way of saying yes, it has tons of instructions.
17:42:23 <KipIngram> They just kept piling them on and finding some way to stick them in.
17:42:39 <dave0> siraben: the 16 bit x86 was as complicated as the z80
17:43:02 <siraben> Recently I'm working on a way for me to input to a program the available register movement operations and the stack effect.
17:43:06 <siraben> The idea is that it would generate assembly code for, say ROT without me lifting a finger.
17:43:17 <KipIngram> Heh heh heh.
17:43:21 <dave0> siraben: i386 and later got a bit more sensible
17:43:23 <siraben> Since there's only a finite number of registers and operations, it's a good way to reduce errors.
17:43:26 <KipIngram> Look into the golang assembler.
17:43:29 <siraben> Ah   I see.
17:43:37 <siraben> KipIngram:  You write Go?
17:43:49 <KipIngram> No, but I watched a video presentation of how they do that part.
17:44:09 <dave0> i believe the go assembler came from plan 9
17:44:11 <KipIngram> They have a "meta assembly language" and they scrape processor data sheets for the info on how to convert that to the processor's machine code.
17:44:35 <dave0> i wish i knew how to write an assembler :-(
17:44:35 <KipIngram> So the compiler generates that meta language, independent of the target.
17:44:50 <KipIngram> Then an automatically generated (right up your alley) piece of code takes it the rest of the way.
17:45:10 <KipIngram> dave9: we can chat about that in PM if you like.
17:50:54 <siraben> I'm interested in writing an assembler as well
17:51:21 <siraben> Well I have the gist of how to write a simple one, with labels and converting instructions to opcodes, I'm figuring out how to make macros work.
17:51:33 <siraben> Scheme has made it very easy to create an assembler.
17:51:54 <KipIngram> Ah, ok, you're further along.  Yeah, I was just going to basically outline the two pass idea.
17:52:06 <KipIngram> Weird - my connection from my Mac to here just got cut somehow.
17:52:13 <KipIngram> I can't even ping my seedbox.
17:52:27 <KipIngram> But I can from a server at the office, and that's how I'm currently connected.
17:52:35 <KipIngram> Screen session was still running - I just attached to it.
17:53:07 <siraben> The hard part of writing an assembler is getting the header of the executable right.
17:53:23 <KipIngram> Oh, certainly.  
17:53:38 <siraben> I've written an assembler that, um, compiles to a list of bytes to be pasted inside another ASM file to be assembled by another assembler
17:53:42 <siraben> But I hope to control the full stack
17:54:02 <KipIngram> Ah, good - back on the home connection.
17:54:45 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
17:54:58 <siraben> This is an abandoned project of mine to compile a small language to Z80
17:54:59 <siraben> https://github.com/siraben/sicp-to-z80
17:55:00 <KipIngram> :-)
17:55:06 <siraben> More of a compiler than assembler
17:56:00 <siraben> Documentation on assembling for my calculator is so scarce I have to read C++ code
17:56:54 --- join: wa5qjh (~quassel@110.54.175.111) joined #forth
17:56:54 --- quit: wa5qjh (Changing host)
17:56:54 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:05:42 --- quit: wa5qjh (Remote host closed the connection)
18:08:37 <KipIngram> It's getting that way all over - most people totally neglect assembly.
18:11:00 <siraben> And for good reason, I suppose.
18:11:17 --- join: wa5qjh (~quassel@175.158.225.213) joined #forth
18:11:17 --- quit: wa5qjh (Changing host)
18:11:17 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:11:51 <KipIngram> Well, I think it's a shame people don't want to understand those deep levels.
18:13:46 <KipIngram> Kind of like the self-driving car thing; next thing you know people aren't going to know how to drive.
18:13:50 <KipIngram> I *like* driving.
18:14:32 <KipIngram> But seriously - if that tech becomes "the norm / commonplace," we'll wind up with people who never bother to learn to drive.
18:14:58 <siraben> For me I think it depends on the level of abstraction people need.  A person who just wants to compute the average of a list of numbers can use a spreadsheet and not worry about it.
18:15:08 <siraben> Of course, the more understanding the better.
18:15:17 <KipIngram> Yes, but I don't consider that "programming."
18:15:23 <KipIngram> That's using an appliance.
18:15:26 <KipIngram> Like a toaster oven.
18:15:49 <siraben> Right.
18:16:37 <KipIngram> We could write a C program with several nested loops, that accesses an array.
18:16:57 <KipIngram> And we could make it so if you traversed the array one way (say by rows), it would fun good, but if you do it the other way it will crawl.
18:17:12 <KipIngram> A programmer should know why that's the case, and how to do it the right way.
18:17:58 <KipIngram> I wonder if any compilers will re-order that kind of thing for you?
18:18:53 <KipIngram> On the other hand, the array might be control registers in a piece of hardware.
18:19:03 <KipIngram> And they might need to be accessed in a particular order.
18:19:23 <KipIngram> So a compiler would have to be awfully smart to know how and when to do that optimization.
18:21:04 <MrMobius> there are ways to tell the compiler those things
18:21:12 <MrMobius> volatile for example is really useful
18:21:20 <KipIngram> Right.  I don't know many of those things.
18:21:29 <KipIngram> But I know how to nest my loops in the right order.  ;-)
18:21:35 <KipIngram> Old school over here.
18:21:50 <MrMobius> the reason people dont write much assembly code is because humans cant do it very well :)
18:21:57 <MrMobius> compared to the compiler
18:22:01 <KipIngram> Not many humans, at least.
18:22:23 <KipIngram> There are people in the business these days that never would have made the cut 30-40 years ago.
18:22:34 <KipIngram> Programming isn't unique in that, though.
18:22:44 <KipIngram> I see it in music, too.
18:23:04 <KipIngram> I'm sure it affects any field that technology has had a large impact on.
18:25:54 <MrMobius> siraben, what do you mean documentation is scarce? isnt it standard Z80 stuff?
18:27:27 <siraben> MrMobius:  No, the way the calculator does signing and so on
18:27:47 <MrMobius> oh i see
18:27:56 <MrMobius> didnt they figure out a way to sign things without TI?
18:28:35 <siraben> Of course, but after looking at some hexdumps there's a checksum at the end
18:28:42 <siraben> Which I don't know how is calculated.
18:28:47 <siraben> it's*
19:01:32 --- quit: dave0 (Quit: dave's not here)
19:25:02 --- join: reich (~reich@71-88-195-60.dhcp.kgpt.tn.charter.com) joined #forth
20:30:24 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
20:32:57 --- quit: pierpa (Quit: Page closed)
20:38:46 --- quit: dddddd (Remote host closed the connection)
20:51:22 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
20:54:25 --- quit: pierpal (Read error: Connection reset by peer)
21:06:50 * tabemann just got a more user-friendly closure interface working
21:08:41 <tabemann> e.g. you can do : foobar 0 1 2 3 4 <: . . . . ;> execute ; foobar 3 2 1 0 ok
21:18:43 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
21:23:13 --- quit: pierpal (Ping timeout: 264 seconds)
21:27:51 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
21:37:49 --- quit: pierpal (Read error: Connection reset by peer)
21:38:58 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
21:42:09 --- quit: ncv (Ping timeout: 252 seconds)
21:43:08 <siraben> Do you mean 4 3 2 1  ?
21:43:09 --- quit: pierpal (Ping timeout: 240 seconds)
21:46:15 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
21:46:26 <dave0> re
21:48:26 --- join: pierpal (~pierpal@host247-234-dynamic.18-79-r.retail.telecomitalia.it) joined #forth
21:55:54 <tabemann> back
21:55:57 <tabemann> no, 3 2 1 0
21:56:05 <siraben> What happened to 4?
21:56:12 <tabemann> 4 is the number of cells to enclose
22:04:14 <tabemann> this is the first non-garbage-collected implementation of closures I have personally encountered (even though I suspect C++11 may also have such)
22:16:40 <siraben> So what happens if I push numbers before foobar/
22:16:40 <siraben> ?
22:16:49 <siraben> 7 8 9 foobar => 3 2 1 0 ok ?
22:17:42 <tabemann> foobar doesn't take any arguments on the stack
22:18:00 <tabemann> however, you could make a function : quux 4 <: . . . . ;> ;
22:18:22 <tabemann> that when you execute 7 8 9 10 quux it outputs an xt
22:18:42 <tabemann> which when executed outputs 10 9 8 7
22:19:47 <tabemann> I should go to bed though
22:20:51 <siraben> huh I thought it did stack capture
22:21:07 <tabemann> it does do stack capture
22:21:24 <tabemann> it's just that in my original function, the function provided the arguments already
22:21:54 <tabemann> and it captures the number of arguments that you specify at the time of the closure's creation
22:24:59 <tabemann> one neat thing that you can do with this is create an xt that returns a value that is incremented each time it is executed, without using any outside storage visible to the user
22:28:03 <tabemann> : counter 1 cells allocate! tuck ! 1 <: dup @ dup 1+ rot ! ;> ;  ok
22:28:03 <tabemann> $100 counter constant my-counter  ok
22:28:03 <tabemann> my-counter execute . 256  ok
22:28:03 <tabemann> my-counter execute . 257  ok
22:28:03 <tabemann> my-counter execute . 258  ok
22:28:04 <tabemann> my-counter execute . 259  ok
22:29:33 <tabemann> note that allocate! is just : allocate abort" unable to allocate" ;
22:29:42 <tabemann> whoops
22:29:52 <tabemann> note that allocate! is just : allocate! allocate abort" unable to allocate" ;
22:30:04 <tabemann> I should go to bed though
22:33:40 <siraben> Ah, so they're closures!
22:33:50 <siraben> That's good.  Internal state should be hidden.
22:34:01 <siraben> I hate guts spilling out everywhere
22:34:05 <siraben> Sweet dreams.
23:59:59 --- log: ended forth/18.10.23