00:00:00 --- log: started forth/19.02.06 00:37:22 proteusguy: It is a multiboot executable, which can be loaded by a bootloader. You can use it with lilo, GRUB, syslinux and many other bootloaders. 00:37:54 john_cephalopoda, ah so you need lilo or grub to load it then? 00:39:06 Yes. It's an operating system. You need a bootloader to load it. 00:39:22 haha well why not just become the bootloader? ;-) 00:39:37 what mode do you operate the CPU? flat 32? 00:39:58 Right now it runs on x86 in Real Mode. 00:40:13 wow ... is that where you plan to keep it? 00:40:14 It doesn't anything but print out its name. 00:40:55 I plan to move it to protected mode and support more architectures some day. 00:41:26 I've always been curious how virtual 8086 mode worked but never seen anyone use it. Imagine a thousand little virtual 8086 actors all communicating to each other. Wonder how the performance would be. (I'm guessing pretty bad) 00:42:11 Just a PITA to jumpstart the CPU into protected mode. But yeah - that's probably what's most effective for that architecture. 00:44:15 Protected Mode offers virtual memory and access to more memory, so that's nice. 00:44:37 But even worse than going from real to protected is going from 32 bit to 64 bit mode. 00:45:16 yeah it's like learning how to shift a semi-tractor engine. chunk bang whack kerchang! 00:49:32 Maybe I should start defining my forth dialect (or find a nice one to implement). 01:10:05 --- join: xek (~xek@apn-31-0-23-83.dynamic.gprs.plus.pl) joined #forth 02:02:30 --- quit: ashirase (Ping timeout: 245 seconds) 02:07:46 --- quit: smokeink (Remote host closed the connection) 02:25:57 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 02:31:12 --- quit: gravicappa (Remote host closed the connection) 02:41:41 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:45:06 yea do it 02:58:36 --- quit: smokeink (Remote host closed the connection) 03:05:19 --- quit: Croran (Ping timeout: 240 seconds) 03:13:33 --- join: Croran (~quassel@2601:601:1801:6dde::4276) joined #forth 03:49:37 Tabemann: I went on Github for a quick peek at your draft VM spec. 03:49:37 Is it hashforth/doc/arch.md ? 03:49:38 That document mentions Forth interpreter/compiler level constructs 03:49:38 (headers, names, word counts, CREATE) that are not germane to the 03:49:39 machine Forth level. 04:10:11 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 04:22:18 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:25:37 --- join: nerfur (~nerfur@broadband-95-84-184-13.ip.moscow.rt.ru) joined #forth 04:41:01 Croran: Lina is the linux build of ciforth 04:41:46 nasm and m4 are used to build ciforth for a given architecture or OS 05:03:21 --- quit: rdrop-exit (Quit: Lost terminal) 05:20:38 --- quit: dave0 (Quit: dave's not here) 05:30:09 --- quit: pierpal (Quit: Poof) 05:30:27 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 05:48:28 --- join: gravicappa (~gravicapp@h109-187-17-233.dyn.bashtel.ru) joined #forth 05:50:39 --- quit: Zarutian (Read error: Connection reset by peer) 05:51:20 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 06:10:59 --- quit: smokeink (Remote host closed the connection) 07:18:34 rdrop-exit: yes, that's it - and yes, it's a bit higher level than it could be, but some of those things are needed because, e.g. images need to encode the names of words in them 07:19:21 and the mention of CREATE is that the VM has a distinction between colon words and CREATEd words 07:19:41 oh he left 07:21:52 why do you need to distinguish? 07:22:00 different handler? 07:22:57 because CREATEd words have no code compiled for them 07:23:41 all they do is push the value that as passed to NEW-CREATE when the word was created 07:24:27 but I have to go to work now 07:24:29 bbl 07:28:49 --- quit: tabemann (Ping timeout: 240 seconds) 07:59:03 --- quit: pierpal (Quit: Poof) 07:59:21 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 08:09:32 --- quit: nighty- (Quit: Disappears in a puff of smoke) 08:14:44 --- join: tbemann (~androirc@2600:380:c539:fb32:9eb1:81cd:5f09:d25d) joined #forth 08:15:28 --- quit: tbemann (Client Quit) 08:26:58 --- quit: xek (Remote host closed the connection) 08:27:21 --- join: xek (~xek@apn-31-0-23-83.dynamic.gprs.plus.pl) joined #forth 08:47:15 well that is code, no? 08:47:50 man, I had such a pain sign-extending an unsigned bitfield. 08:48:20 in C? 08:48:43 Yeah, I dunno if I am getting senile or it's the weather.. It was a fight. 08:49:01 unsigned sign extension is just 0s 08:49:07 invert bits and add one - should be trivial. 08:49:22 wa 08:49:27 seems complicated 08:49:40 i mean, the solution 08:50:01 corecode: unsigned bitfield. "now represent those bits as a full cell of SIGNED VALUE" 08:50:29 so it is a signed bitfield 08:50:41 so, if you got 5 bits, you got an unextended sign bit, and payload. 08:51:13 Yeah, I had to cave and just used a buried struct in a func and extracted a signed bitfield. 08:51:20 aha 08:51:45 but it SHOULD be "trivial".. r, I am getting very, very old. 08:51:52 r/or 08:52:13 or: (int32_t)unsigned_5_bit << (32-5) >> (32-5) 08:52:29 anyway, it works. But, I am not sold on opcodes/packing oddballs sizes for shits & giggles. 09:32:16 --- quit: Zarutian (Read error: Connection reset by peer) 09:32:57 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 10:02:23 --- join: xek_ (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth 10:04:58 --- quit: xek (Ping timeout: 250 seconds) 10:36:25 --- join: tbemann (~androirc@2600:380:c539:fb32:9eb1:81cd:5f09:d25d) joined #forth 10:38:07 --- quit: tbemann (Client Quit) 10:55:19 --- quit: gravicappa (Ping timeout: 240 seconds) 12:41:40 --- quit: pierpal (Quit: Poof) 12:41:57 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 12:50:57 --- join: xek__ (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth 12:53:09 --- quit: xek_ (Ping timeout: 240 seconds) 13:03:27 --- quit: pierpal (Quit: Poof) 13:03:46 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 13:17:49 --- quit: xek__ (Ping timeout: 240 seconds) 13:32:41 PoppaVic: weird - was looking at precisely the same thing today - 10 bits in my case 14:17:08 --- join: john_metcalf (~digital_w@host86-172-212-236.range86-172.btcentralplus.com) joined #forth 15:09:17 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 15:10:07 hi 15:36:13 hi dave0 15:42:19 hi john_cephalopoda 16:22:14 WilhelmVonWeiner: Given Lina is the 'linux build of ciforth', why doesn't it recognize core Forth words when I start it normally? It appears it won't recognize any Forth word unless I start it with the '-e' command line switch. 16:29:07 WilhelmVonWeiner: I may have just answered my own question. It's apparently case sensitive unless you use the -e option to load 'system electives'. 16:34:52 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 16:36:05 * Croran renames lina64 to LINA64 to keep things caps lock compatible 16:36:32 (u&UINT64_C(1<<5)) -UINT64_C(1<<5) 16:36:58 assuming u is uint64_t 16:41:39 oops, make that (u^UINT64_C(1<<5)) -UINT64_C(1<<5) 16:42:00 which boils down to (u^32)-32 16:43:34 that looks a lot like c code 16:44:34 yes 16:48:36 actually, PoppaVic was asking for a 5-bit field, rather than using bit #5 as a sign bit, so make that (u^16)-16. 16:49:53 I shouldn't post code before coffee 16:51:06 oh i see 16:51:47 brb 16:51:54 i use a different trick (u & 0xf)-(u & 0x10) where 0x10 is the sign bit 16:55:17 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:56:55 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:57:29 Mine assumes the upper bits are already zeroed out. 16:58:44 But it all boils down to the same thing. 17:00:37 c[_] 17:05:31 BTW, good morning dave0 17:08:20 hi rdrop-exit :-) 17:08:38 :) 17:25:42 --- join: travisb (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:26:40 rdrop-exit, I put names in the VM so it can display them during tracing 17:27:19 I have thought of ways of making the VM not have to know about names or like, but I haven't thought up a way that that can be combined with efficient tracing 17:33:46 I think you're trying to bake too much of the develoment environment related constructs into the VM level. 17:34:58 As I mentioned the other day, the VM shouldn't care how the image was produced. 17:36:15 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 17:37:17 I've already removed wordlists from the VM aside from words forming linked lists - but the VM doesn't dictate what those linked lists are used for 17:37:44 words do have flags in the VM, but those flags are completely up to the user to define the meanign of 17:38:21 (they're in the VM so that the image can specify what the flags are, so the user can, in the image, say that such and such words are immediate or compile-only) 17:38:53 rdrop-exit: if he's going to insist on a binary-format, the VM has to be aware of it. I do agree: far too much bolted in. 17:39:14 You're still conflating the development environment and the VM. 17:39:50 I did think of ripping out word names from the VM, but I couldn't figure out a convenient way of doing so which preserved efficient tracing 17:40:12 because tracing is just too useful to get rid of 17:40:29 it's not VM - it's extensions. 17:41:24 I can't recall ever "tracing" a forth word.. Maybe waay back on F83 or F-pc... Given a View-screen - why bother? 17:41:25 actually activating tracing is done with services and is completely optional 17:41:42 buffer 6 17:43:50 Ooops. 17:43:51 Sorry. 17:44:03 :)) 17:44:49 tracing in hashforth displays each word executed's name, how deep the return stack is when it is executed, and the state of the data stack at that point in time; I find it very useful in figuring out what is going on when hashforth decides to crash (I redo what I was doing, but execute "true set-trace" right before the point at which I think it crashed) 17:45:31 much, much more useful than using gdb on hashforth 17:47:21 it's baked into the VM, yes, and that's what allows it to be efficient - I've thought of ways to do tracing that don't involve baking it into the VM, and they are simply inferior to supporting it in the VM 17:48:23 once again Call it an 'emulator' for doze/dos/linux and the assembler-side - leave it out of the VM. (but that's me - ymmv) 17:51:52 the assembler is currently written for attoforth, what rdrop-exit was referring to was my intent on making the assembler self-hosting so hashforth can compile its own images 17:51:56 You can always add debug registers and a debug port to the VM for use by the development environement, none of that requires dragging in interpreter/compiler level contructs into the VM. 17:52:15 +--------------------+ 17:52:15 | Running Image | 17:52:15 +--------------------+ 17:52:15 | Virtual Machine | 17:52:17 +--------------------+ 17:52:20 | Platform | 17:52:22 +--------------------+ 17:54:04 currently the debugging-related functionality is in optional services 17:54:25 --- join: X-Scale` (~ARM@33.5.158.5.rev.vodafone.pt) joined #forth 17:54:33 Whether there is a particular Forth interpreter/compiler running as part of the image is not a concern of the VM. 17:56:35 --- quit: X-Scale (Ping timeout: 272 seconds) 17:56:35 --- nick: X-Scale` -> X-Scale 17:58:14 yes - as implemented one could load an image for a different Forth interpreter/compiler; the only parts it assumes is that there is a data stack and a return stack and each word has a name, a code pointer (which points to native code), a data pointer, a ttc pointer, a flags value (whose value it doesn't care about), and a next value (which for primitives points to the previous primitive, but could be used for anything) 17:58:45 and of course it assumes the binary format for the ttc code 17:59:16 Again you are conflating the interpreter/compiler level, the machine Forth level. 17:59:41 * and the machine Forth level. 18:02:51 For example I write an assembler that runs on your 64-bit VM and targets code for your 16 bit VM target. Why are you forcing name-related stuff on my target? 18:03:00 I was thinking of ripping out the names, flags, and next value and putting them in a data structure allocated internally by the image, but I couldn't figure out how to get tracing working without at least the names value 18:04:54 From the point of view of the VM, the compiler/interpreter is just an application. 18:04:55 what I did think of is having, in (a highly optional) trace mode, for each word executed the runtime calls a particular forth word specified via a service which then looks up the name 18:05:24 but I couldn't think of how that would have at all acceptable performance 18:06:09 maybe have a defined format for an optional name table which is then registered with the VM via a (highly optional) service 18:07:09 that way it can both be fast yet completely optional 18:08:08 bbiab 18:15:05 --- quit: travisb (Ping timeout: 250 seconds) 18:15:13 --- quit: pierpal (Remote host closed the connection) 18:27:17 You're inverting the debugging problem, debug facilities on the VM can be a combination of instructions/registers/ports that give you access to internal state. Correlating that internal state, deriving meaning out of that is outside the purview of the VM, it's at the level of your development environment. 18:47:29 bbiab 18:47:45 I don't even plan on exposing any "registers" above the VM implementation. 18:48:36 ..if I find a reason to do so, I'll add a 'syscall' to report states or single-step, or whatever. 18:53:07 --- quit: dave0 (Quit: dave's not here) 18:53:37 Stack machines have less internal state then register machines (unless your using on-chip stacks), so any debug facilities are trivial in comparison. 18:58:39 Although our SYS instruction won't always be amenable for debugging purposes since it isn't stack neutral. 19:01:22 Taking a snapshot of register space is better done by a dedicated instruction. 19:01:28 sw or chip-emulator or chip: you can tell them you are debugging. I know the ARM chips have EDG (but damned if I ever used it). 19:05:32 Yes, I don't foresee any issues. 19:06:29 I suspect you'd want to have a serial channel, and a syscall to point at a word to trace, and - off to the races. 19:17:31 --- join: gravicappa (~gravicapp@h109-187-17-233.dyn.bashtel.ru) joined #forth 19:30:33 --- join: travisb (~travisb@2600:1700:7990:24e0:e50e:f5cd:64e7:bcff) joined #forth 19:30:37 Gotta go, catch you all later. Keep on Forthin' 19:30:47 --- quit: rdrop-exit (Quit: Lost terminal) 19:31:31 --- quit: dddddd (Remote host closed the connection) 19:31:41 --- join: smokeink (~smokeink@118.131.144.142) joined #forth 20:10:02 --- quit: proteus-guy (Ping timeout: 264 seconds) 20:15:51 Is there a floating point library for ciforth? 20:16:21 I tried loading the included assembleri86 library but it fails. 20:16:43 The manual seems to indicate the library isn't intended for 64-bit platforms? 20:19:10 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 20:20:47 --- join: proteus-guy (~proteusgu@2403:6200:88a6:329f:7cde:e268:d830:d8c7) joined #forth 20:33:01 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 20:33:09 re 20:37:24 hi dave0 20:37:49 hi crc 20:45:31 * crc has finished initial unix man pages for the retro executable and supporting tools used to build a new system 22:09:34 --- quit: pierpal (Remote host closed the connection) 22:29:21 crc, cool! keep posting links! 23:14:05 --- quit: john_metcalf (Quit: http://corewar.co.uk) 23:59:59 --- log: ended forth/19.02.06