00:00:00 --- log: started forth/19.01.09 00:19:11 --- quit: gravicappa (Ping timeout: 250 seconds) 01:29:24 Finally fixed ' and added ['] 01:29:32 I was using a smart state tick at first 01:33:40 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:42:01 --- quit: pierpal (Ping timeout: 246 seconds) 01:43:03 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:43:51 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 01:49:06 --- nick: Keshl_ -> Keshl 02:02:05 --- quit: pierpal (Ping timeout: 246 seconds) 02:04:09 --- quit: ashirase (Ping timeout: 272 seconds) 02:07:01 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:12:06 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 02:16:43 --- quit: pierpal (Ping timeout: 252 seconds) 02:20:24 --- join: `preside1 (~presiden@unaffiliated/matematikaadit) joined #forth 02:22:58 --- quit: `presiden (Ping timeout: 246 seconds) 02:27:15 Just did my first hardware test, the calculator works exactly as expected. Phew. 02:38:42 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 02:43:25 --- quit: pierpal (Ping timeout: 268 seconds) 03:05:52 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 03:07:25 --- quit: pierpal (Read error: Connection reset by peer) 03:07:37 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 03:27:49 --- quit: pierpal (Read error: Connection reset by peer) 03:28:08 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 04:29:00 heh - 10 0 do i loop v. 0 10 do i loop <- i decided to accept the latter and adjust the increment accordingly - avoids (some) overflows and is a nice way to do a reverse iteration 04:31:11 $ rpany 0 5 do i loop dump-short clear 5 0 do i loop dump-short 04:31:13 '5' '4' '3' '2' '1' 04:31:15 '0' '1' '2' '3' '4' 04:31:17 y 04:33:43 arguable i suppose - reversal is offset by 1 - shrug 04:36:25 --- quit: pierpal (Quit: Poof) 04:36:37 --- quit: dave0 (Quit: dave's not here) 04:36:41 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 04:38:00 tabemann: hashforth missing include/hf/loader.h and an `hf_load_image` function 04:45:48 --- quit: mtsd (Quit: WeeChat 1.6) 04:56:21 attoforth builds on freebsd (needs gnu make), but segfaults when `bye` is used: https://forthworks.com/share/e296b7f03519123b163fb277979ac8df 04:58:59 on openbsd, attoforth can be compiled using gnu make and clang, but segfaults when run: https://forthworks.com/share/191f60c26a418f01c9741add63aa2323 04:59:10 crc: When you use "bye", you don't want the program to run any more anyway ;Ã¾ 05:03:56 john_cephalopoda: true, but I also don't want core dumps :) 05:30:32 --- join: grosged (~grosged@bop62-1-88-178-198-84.fbx.proxad.net) joined #forth 05:37:14 hello there 05:37:19 siraben ? 05:37:39 grosged: hello! 05:37:46 hello :) 05:37:55 what's up ? 05:38:03 grosged: great to be able to talk, thanks for sending in those pull requests! 05:38:05 I see you keep on good working 05:38:10 I was wondering how to contact you, hehe 05:38:30 ;) 05:38:44 So you're a TI-84 ASM programmer as well? 05:38:45 my last PR gives travis fail 05:38:59 Ah let me see 05:39:25 er...I used to program in z80 assembler a long time ago (Amstrad CPC !) 05:39:48 then I went back a few years ago , thx to TI calcs ;) 05:39:51 Ah, you need to change (ex de hl) to ((ex de hl)) 05:39:58 This is somewhat annoying, I need to update my assembler 05:40:24 ah ok , I modify ... 05:40:29 commit to it again and it Travis should accept 05:40:51 ok I'll try to manage (I'm not an github expert at all !! hehe) 05:41:01 grosged: have you been able to run the ROM? 05:41:24 I work thru github online only (browser) 05:41:38 I confess I did not try 05:41:54 Ah, because it runs a test suite which allows you to verify everything 05:41:55 https://www.cemetech.net/projects/jstified/ 05:42:06 maybe you'll propose easier way soon 05:42:10 hehe :) 05:42:27 so to make the ROM, run "make build" in the folder (with Guile installed), and drag the ROM into the calculator window 05:42:35 Yeah I'd like to integrate it all into Travis 05:42:38 I'll try 05:42:56 But Z80 emulators don't seem to have CLI 05:43:19 I can get this emulator to build: https://github.com/KnightOS/z80e but its flash memory emulation is incorrect so my ROM doesn't work 05:44:07 please tell me which line for the ( ex de hl) ? 05:44:20 All of the (ex de hl) should be replaced with ((ex de hl)) 05:44:29 (I'm searching...) 05:45:02 So the first line seems to be 834 05:45:07 ok 05:45:21 and that looks like it's the only one 05:46:00 ok thx 05:47:04 I've noticed that 0JUMP = 0BRANCH 05:47:15 exactly the same routine 05:47:44 0BRANCH is a relative jump, whereas 0JUMP is an absolute jump 05:48:19 Oh 05:48:45 but the z80 routines are equal 05:49:07 I'm afraid I don't understand hehe 05:49:19 Nearly equal 05:49:23 (beginner in Forth) 05:49:26 notice that in 0JUMP there's (jp jump) 05:49:44 Wheras in 0BRANCH there's (jp branch) 05:50:07 ah yes !! 05:50:19 Don't worry, I implemented 0JUMP because handwriting address offsets became tedious 05:50:30 If you program in the Forth layer you never need to see the JUMP or BRANCH stuff 05:50:53 grosged: your pull request builds but the ROM doesn't run 05:50:54 you notice I also changed a few JP's into JR's ...That'll be okay ? 05:51:08 Maybe you can revert the changes to 0JUMP? 05:51:12 It should be 05:51:25 What's the benefit in using JR over JP? 05:51:44 inside a routine, JR is a little bit faster 05:52:05 and 1 byte less 05:52:41 oops ! trouble from 0JUMP you said ? 05:52:52 grosged: how were you able to do TI development in the past without an emulator? 05:52:56 I think so 05:53:22 only with an assembler and a physical calc 05:53:34 old-school way hehe :) 05:53:38 By the way I can make an upgrade file now 05:53:55 I tested it on a TI-84 05:54:20 so no need to go back to old 0JUMP version ? 05:54:34 Completely harmless, just reflash the operating system by taking out the batteries, plugging in a cable, holding DEL and then ON 05:54:55 grosged: let me see which one is the faulty 05:55:00 ok 05:55:46 JUMP is correct, checking more. 05:56:14 by the way, if you intend to program exclusively for TI-84 models , I can suggest you my version of fastcopy (which is 4 times faster than fastcopy) 05:56:29 (see https://www.cemetech.net/forum/viewtopic.php?t=12282&start=0 ) 05:57:41 Yeah this basically locked to TI-84 model 05:58:11 (or https://tiplanet.org/forum/viewtopic.php?t=17755&p=194206 ) 05:59:09 so , not for any TI-83+, then 05:59:13 ok :) 05:59:25 Ah tu peux parler franÃ§ais 05:59:27 Je peux parler un peu 05:59:36 oh super! 06:00:31 mais l'anglais ne me dÃ©range pas , non plus ;) 06:03:31 grosged: you should try installing guile so you can build the rom 06:05:10 ok..."sudo apt-get install guile-2.2" 06:05:20 ... 06:05:48 And you should be able to run it in the emulator 06:06:06 To see if any bugs occur 06:08:52 grosged: try running "make build" in the directory 06:09:24 In my version of 0JUMP : jp jump is missing 06:09:50 What do you mean? 06:09:57 Is there an error during the build? 06:10:18 I'm checking 06:10:45 It may not be obvious but a lot of labels are automatically generated by defcode, defword and other macros 06:11:31 The assembler resolves all references 06:11:45 I confirm : my 0JUMP version is bad 06:11:58 I'll modify that 06:13:29 --- join: dddddd_ (~dddddd@unaffiliated/dddddd) joined #forth 06:15:22 travis is checking... 06:15:43 grosged: are you also able to build it locally? 06:15:59 perhaps 06:16:13 I did not try yet 06:16:43 Should be pretty simple once you get guile installed :) 06:17:05 only in pure "z80 world" at the moment ;) 06:17:20 I'll read again your guide 06:17:36 about settings/building 06:19:19 hehe, pure "z80 world" in Scheme :) 06:19:32 haha yep ! 06:19:32 grosged: what do you think of my assembler, by the way? 06:19:51 the ( ) 06:19:59 I'm not used to 06:20:14 Ah yeah, Lisp syntax :) 06:20:58 I read we need NIX 06:21:04 dunno NIX 06:21:43 Don't worry about it, that's why I have a Makefile 06:21:51 Do you have guile installed yet? 06:22:26 https://www.gnu.org/software/guile/ ... this is guile ? 06:22:34 yes, now installed 06:22:36 grosged: yes 06:22:40 What distro are you running? 06:22:41 Then cd into the directory and run "make build", then you should see a new file called zkeme80.rom 06:22:44 linuxmint 06:22:48 32bit 06:22:53 last one 06:22:57 Does "make build" work? 06:23:03 I test 06:23:05 ... 06:24:42 I vae some warnings 06:24:44 have 06:24:51 like " warning: possibly unbound variable `make-rom'" 06:24:55 The warnings are fine 06:24:58 ok 06:25:11 ...compiling.. 06:25:34 It will be a little bit slow the first time, but on subsequent builds it's faster. 06:25:45 Pass one... 06:25:45 End of forth.asm: 0x18a8 06:25:46 End of zkeme80: 0x2d14 06:25:46 There are 4844 bytes left for page 0. 06:25:46 Start of Forth data: 0x829e 06:25:46 There are 354 bytes left for page 2. 06:25:48 End of Forth data: 0xd415 06:25:50 There are 11243 bytes left for page 3. 06:25:52 End of binary: 0x100000 06:25:53 --- nick: dddddd_ -> dddddd 06:25:54 Pass two... 06:25:56 $1 = #t 06:25:58 scheme@(guile-user)> 06:25:59 Looks good :) 06:26:02 seems good 06:26:16 So go to https://www.cemetech.net/projects/jstified/ 06:26:38 yes 06:26:44 I need a rom 06:26:48 for that 06:27:04 And click the ROM tab 06:27:04 I mean : a ti-84 rom , right ? 06:27:05 load it in 06:27:13 ok 06:27:18 Yeah 06:27:20 zkeme80.rom 06:28:09 success ! 06:28:15 How many tests pass? 06:28:39 163 / 163 06:28:54 Yay :) I'll accept your PR 06:28:56 but that was not including my last pr 06:29:27 I downloaded your version 06:29:34 not mine including my las pr 06:29:40 wait! 06:29:46 ! 06:29:50 Oh ok. 06:30:00 I redo 06:30:05 So now you know how to test everything 06:30:21 I only ever commit when all the tests pass 06:30:23 & I thank you for that ! 06:32:45 No problem. 06:33:04 --- quit: dddddd (Read error: Connection reset by peer) 06:33:22 my fork = 163/163 too 06:33:26 ! 06:33:41 Can you update your commit? 06:33:47 Travis reports fail 06:33:56 your PR* 06:36:54 still failure from Travis 06:36:57 mm 06:37:07 grosged: and is it failing locally? 06:37:18 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 06:37:44 If "make build" fails, then type ",bt" (without quotes) in the Guile REPL to see the backtrace 06:37:53 that's the kind of situation in github that gets me lost 06:38:45 on my terminal console, "make build" was ok 06:39:01 Ok let me check travis 06:39:11 make build 06:39:11 rm -f zkeme80.rom 06:39:11 echo '(begin (load "zkeme80.scm") (make-rom "zkeme80.rom"))' | guile 06:39:11 GNU Guile 2.2.3 06:39:11 Copyright (C) 1995-2017 Free Software Foundation, Inc. 06:39:12 Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. 06:39:13 This program is free software, and you are welcome to redistribute it 06:39:15 under certain conditions; type `,show c' for details. 06:39:17 Enter `,help' for help. 06:39:19 ;;; :1:28: warning: possibly unbound variable `make-rom' 06:39:21 Pass one... 06:39:23 End of forth.asm: 0x18a8 06:39:25 End of zkeme80: 0x2d14 06:39:27 There are 4844 bytes left for page 0. 06:39:29 Start of Forth data: 0x829e 06:39:33 There are 354 bytes left for page 2. 06:39:35 End of Forth data: 0xd415 06:39:37 There are 11243 bytes left for page 3. 06:39:39 End of binary: 0x100000 06:39:40 grosged: use a paste bin 06:39:41 Pass two... 06:39:43 $1 = #t 06:39:45 scheme@(guile-user)> 06:39:54 grosged: https://paste.debian.net/ 06:39:58 don't paste multiple lines into IRC :) 06:40:12 ah? 06:40:20 grosged: that looks like a successful build 06:40:27 I think you need to push your commit 06:40:47 wait 06:40:57 Sorry it's not your scheme changes that's failing 06:41:39 Looks like I need to change how travis does its build 06:41:48 I'll merge your PR and update the build process. 06:42:47 ok 06:45:20 on jstified 06:45:27 after a few tests 06:46:01 I have a blank screen...still testing ?... or freeze ?* 06:46:47 grosged: that means something broke 06:46:50 What did you change? 06:47:03 Did you recompile and reload the ROM? 06:47:10 Oh you mean when you click through 06:47:13 yes : my version 06:47:14 don't worry, that's just shutdown 06:47:20 ah 06:47:30 It's all in the .fs files 06:48:09 I confirm that was just a shutdown as I can power on 06:50:12 As long as you can see the tests, everything's OK 06:51:07 grosged: how's learning Forth coming along? 06:51:20 grosged: I recommend https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf 06:51:51 thx I've heard of this book 06:52:03 Currently I still don't have a REPL... but you can do the examples by editing the .fs files and recompiling 06:52:17 I recommend modifying bootstrap-flash3.fs 06:52:34 Since flash1 is for tests and flash2 is memory constrained 06:52:39 Until now, I'm playing a bit in forth on my computer, using gforth 06:52:44 or pforth 06:52:55 grosged I see. 06:54:49 grosged: do you know Scheme? 06:55:14 not at all 06:56:07 I see. 06:57:02 0JUMP modified 06:57:15 (was not satisfied :) ) 06:57:54 what d'you think of my fastercopy 06:57:56 ? 06:58:08 interested? 06:58:53 I could try it in my fork 07:00:43 I'm gonna go 07:00:51 thx for your patience 07:00:55 & advices 07:01:20 I let you program ;) 07:01:49 was nice to communicate with you there ! 07:02:06 see you later, bye ! 07:03:00 grosged: see you around! 07:03:08 --- quit: grosged (Quit: Leaving) 07:09:41 --- join: gravicappa (~gravicapp@h109-187-2-216.dyn.bashtel.ru) joined #forth 07:11:25 * Zarutian is musing about the design of an FPGA like device which is only made up of async LUTs and bus routing boxes (probably memristor based too) 07:16:06 --- join: Kumool (~Khwerz@adsl-64-237-235-188.prtc.net) joined #forth 07:23:04 --- quit: tabemann (Ping timeout: 252 seconds) 08:30:22 --- join: grosged (~grosged@bop62-1-88-178-198-84.fbx.proxad.net) joined #forth 08:30:31 hi again 08:31:28 siraben, when building your version, I had this error "Pass two... 08:31:28 ERROR: In procedure scm-error: 08:31:28 Label not found: current-input-device 08:33:09 (at the moment I've deleted my fork but copied/pasted my modifications into a file for later ;) ) 08:59:17 --- quit: pierpal (Quit: Poof) 08:59:37 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 09:27:57 --- join: proteusguy (~proteus-g@58.10.154.246) joined #forth 09:27:57 --- mode: ChanServ set +v proteusguy 09:33:49 --- quit: nighty- (Ping timeout: 240 seconds) 09:35:26 --- quit: grosged (Quit: Leaving) 10:16:09 --- quit: gravicappa (Ping timeout: 240 seconds) 11:25:26 --- quit: pierpal (Read error: Connection reset by peer) 11:26:51 --- join: dys (~dys@tmo-119-14.customers.d1-online.com) joined #forth 11:31:46 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 11:40:24 --- quit: `preside1 (Quit: WeeChat 2.4-dev) 11:57:19 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 12:06:37 --- quit: pierpal (Read error: Connection reset by peer) 12:17:09 --- quit: X-Scale (Ping timeout: 240 seconds) 12:19:05 --- join: X-Scale (~ARM@83.223.249.39) joined #forth 12:55:02 --- quit: mtsd (Quit: WeeChat 1.6) 13:39:21 ok - unnecessary syntax here, but i do kinda have an idea about using this nested word definition thing i mentioned the other day - this provides a simple shell in my project: 13:39:24 https://gitlab.com/lilo_booter/rpany/blob/master/bin/rpany-shell 13:41:09 basically, the shell-run word contents include all the words for the shell - the inner words are added to the dictionary when shell-run is invoked 13:42:14 $ ./bin/rpany-shell 13:42:15 > : shell-post dump-short ; 13:42:17 > 1 2 3 13:42:19 '1' '2' '3' 13:43:28 shows an example of it working ... the shell-post is invoked after every read line is evaluated - in this case, i show the contents of the stack in a brief form 13:44:07 the_cuckoo: so a bit like : shell-post "" evaluate ; in ANS Forthis way? 13:44:20 yup 13:45:49 they are parsed and the parsing is cached - when they're executed, we don't need to parse again (though the form is mostly strings at this point...) 13:47:03 i can now apply a sort of jit like optimisation by replacing the string tokens with pointer functions and numerics can be converted 13:49:16 but if i do that i'm unsure how i force a re-evaluation of the running loop if the dictionary changes (iyswim) - i mean, it's easy to do inefficiently (re-evaluate everything if the dictionary changes), but it would be nice to avoid the 'everything' bit :) 13:52:59 there's also a funny :) - if i split a parsed word over multiple lines *inside* the shell, the next iteration of the loop will be treated as input to the parser :D 13:53:44 but i have an elegant (i think) solution to this one... 13:59:08 oh - sorry - i may have misread your question there - shell-post is a custom word you can define which is executed after each line, but yeah - eval is pretty much evaluate, yes 14:22:41 anyway, unsure if i'm boxing myself into a corner with some decisions or just opening up opportunities... like, i allow stack operations on the command line, and this can include stuff like starting a shell (by default, no args does nothing :)) 14:23:37 hence you can use it as a shell command in your scripts for quick and dirty stuff - like do a calc in bash - value=$( rpany 1 2 3 \* + . ) 14:23:51 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 14:26:11 problem is that if i want to start it as a script (like using the shebang in the link above), the command line suddenly has a file name as the first argument - which is slightly problematic, as i don't want 'file names' to be pushed directly the stack (they'd be rejected as not in the dictionary) 14:27:56 --- quit: pierpal (Ping timeout: 246 seconds) 14:28:43 for now, since i have a special function for parsing the command line args anyway, i just have a special case - the first arguments can be files - after that, all args are passed to the stack as tokens 14:30:45 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 14:31:33 only issue is if i discover a file name which happens to be the name of the word i want to run... 14:32:18 If all else fails, grosged: find and replace 14:32:19 current-input-device in forth.scm without changing the defvar expression 14:37:45 --- quit: MrMobius (Read error: Connection reset by peer) 14:38:48 (of no interest to anyone, but decided on introducting an optional switch which is considered neither a file nor a token - once specified, no attempt is to identify files - rpany [file]* [--] [token]* (where [something] is optional) 14:41:40 hence: rpany rpany-script -- will ensure no tokens are identified as files, and i don't need some extension to id files - if i find a file, i use it, otherwise i treat everything following as tokens 14:42:59 and: rpany -- will guarantee it for the normal case... anyway, that was all :) 15:29:42 i don't see hence nor and in the channel 15:47:55 --- quit: pierpal (Ping timeout: 245 seconds) 16:05:23 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:05:36 Can anyone suggest me a solution for a 60Hz timer in gforth 16:06:33 I could probably use `utime` and variables but I was wondering if anyone had a better idea 16:06:57 unlikely. If it's running atop an OS, like linux, you are time-slicing anyway. 16:07:13 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:16:45 yeah, my thoughts exactly. annoying. 16:16:47 the alarm syscall 16:17:58 all the OS will promise is that at LEAST x amount of time has elapsed. To even discover the latest 'time' I believe you are now required to post queries and waste MORE time to ascertain what really elapsed-since-last-whatever 16:19:45 if yer running on a pi or something, you might be able to ask for a WDT or something to update or event-post.. I dunno. On a lappy, I'd just poll a clock on occasion; on a controller, you either can use a systick-thingbob or wire in a real RTC. 16:32:40 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 16:32:49 --- quit: pierpal (Read error: Connection reset by peer) 16:33:10 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 16:40:29 --- quit: pierpal (Read error: Connection reset by peer) 16:40:44 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 16:46:01 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 16:46:50 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth 16:47:12 hi 16:47:36 hello dave0 16:47:45 what's up 16:49:22 hi WilhelmVonWeiner 16:49:40 coffee is up! C4[_]~ C8[_]~ C3[_]~ C2[_]~ 16:51:01 same actually 16:51:17 double espresso 16:51:32 i only have instant :-( 16:51:50 I use this "sage" espresso machine 16:51:58 grinds the beans too 16:52:05 oh nice! 16:52:09 but that's kind of annoying because you get stale beans 16:52:33 stale coffee dust and beans 16:52:35 oh does it grind some beans each time you have a cup? 16:52:35 --- quit: pierpal (Read error: Connection reset by peer) 16:52:50 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 16:52:59 yeah 16:53:19 cool! 16:53:43 i like the good stuff 16:53:49 my old man keeps the beans container full all the time, so you just have these beans losing freshness over the 3/4 days it takes to cycle through them 16:54:02 still better than instant so I shan't complain further 16:54:51 Greetings Forthwrights 16:54:53 i heard that light destorys coffee beans 16:54:57 hi rdrop-exit 16:55:08 Hi Dave0 16:55:25 sunlight makes it stale yeah 16:55:44 bummer 16:56:20 I just made my first cup of the day 16:56:41 C4(___)~ C8(___)~ C3(___)~ C2(___)~ 16:57:20 double espresso 16:57:41 espresso is _class_ 16:58:08 espresso is the only way to kickstart my brain 16:59:52 I should be going to bed, but I thought I'd bash out the graphical code for this chip-8 interpreter before 17:00:10 should take less than an hour to write it once, delete it all and rite it again 17:00:26 s/rite/write 17:00:37 oh no that's an awful regex 17:00:41 you get my point 17:00:48 Cool 17:01:39 I ran it through `wc` and the file is 1260 words including stack and documentation comments 17:02:11 I think I could half that by refactoring my opcode words alone 17:02:27 maybe I'm being a little hyperbolic 17:02:46 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 17:04:26 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:28:39 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 17:28:40 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 18:03:36 okay, for whoever wants to use hashforth, I just fixed a bunch of annoying bugs in it, and now comments and s" strings work correctly 18:07:12 now it also has ." 18:12:29 --- quit: tabemann (Ping timeout: 240 seconds) 18:31:52 --- quit: dddddd (Remote host closed the connection) 18:34:27 What is the meaning of "Token type of image does not match configuration"? Why is a token type needed? 18:39:34 --- quit: proteusguy (Remote host closed the connection) 18:39:35 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 19:05:09 No token, no bus/subway-ride.. No soup for you 19:07:56 tabemann: it compiles (using GNU make) and runs on OpenBSD (I had to set the CFLAGS to "-DCELL_64 -DTOKEN_16_32" to use the provided image) 19:13:38 Ah grosgred left 19:13:43 grosged* 19:17:04 I still don't understand why a token type is needed. My understanding was that there would be 3 standardized stack machine VM targets, one each for the 3 common cells sizes, 16/32/64 bits. An image file intended that conforms to the ISA of the 16-bit-cell VM will run on any implementation of the 16-bit-cell VM, and the same applies for a 32-bit-cell image file on a 32-bit-cell VM, and a 64-bit-cell 19:17:10 image file on a 64-bit-cell VM. 19:17:27 I'm not seeing what this token type is, and why it is needed. 19:29:35 back 19:30:12 the reason why is that you might want an 8/16-bit token type on a 32-bit system if the 32-bit system actually has very little RAM (e.g. small ARM systems) 19:30:42 but the 8/16-bit and 16/32-bit token types are slower than the 16-bit and 32-bit token types because there is more decoding needed 19:30:59 so if one cares about speed one might opt for 16 or 32-bit token types 19:32:18 there is no 64-bit token type, because 64-bit tokens would be a waste of bits, and anyways, for most applications, even 32-bit tokens are probably unnecessary 19:33:25 i made everything 64 bits on amd64 for no particular reason 19:33:52 attoforth is 64-bit on amd64, but attoforth is not designed with efficiency in mind 19:34:14 whereas hashforth is meant to scale down to microcontrollers 19:36:50 That seems redundant, the standardized 16-bit-cell ISA would already be designed small targets, and the 32-bit-cell ISAs would already be designed to suit large targets. 19:37:26 the problem is that you really have two types of 32-bit systems 19:37:48 ones that are big, like i386, and ones that are small, like Stellaris/Riva ARM systems 19:37:49 what problem? 19:38:18 the former may have gigabytes of RAM, the latter may have only kilobytes of RAM 19:39:55 So you recommending 4 standardized VMs? i.e. Stack-Machine-VM-16, Stack-Machine-VM-32-small, Stack-Machine-VM-32-large, Stack-Machine-VM-64? 19:39:56 for the former a 32-bit token type makes the most sense because you can afford the RAM usage and you could make use of the extra speed 19:40:07 for the latter every last bit of RAM matterss, so a 8/16-bit token type makes sense 19:40:07 yes 19:41:41 * PoppaVic sighs 19:41:54 You can't have my RAM - try again. 19:42:45 The first step then would be to design the basic 3 ISAs, 16/32/64, and then assess if for practical reasons the 32-bit ISA really needs to be split into two. 19:43:02 look at it this way 19:43:20 with 32-bit ARM there are effectively two different instruction sets 19:43:43 Use bytes.. Aligned is the cell-size, fetch 1, 2 or 4 tokens. Move along ;-P 19:44:08 --- quit: dave0 (Quit: dave's not here) 19:44:37 But that's ARM, very different architecture from a stack machine. 19:44:42 one with 16-bit instructions, and one with 32-bit instructions 19:44:47 the former is known as "Thumb" 19:44:54 the former is often used for microcontrollers, while the latter is aimed at larger systems like cell phones 19:45:08 We have that too, 16/32/64. 19:45:23 There are at least THREE: THumb; arm; and thumb-2 - not to mention devices that mix them a little. 19:45:37 PoppaVic, that is true 19:47:21 You're jumping the gun I feel 19:47:22 and IIRC there's an instruction set in some ARM cores meant for aiding in the execution of Java (ugh) 19:47:38 jizzle or something, yeah 19:48:19 Jazelle 19:48:42 the name seems... ill-fated 19:48:44 well, I wasn't far off ;-) 19:49:03 it's not jizzle, which is a horrible name for obvious reasons, but it is close 19:50:42 I'm curious to compare the ISAs of your 32-small and 32-large. 19:51:25 the difference is that 32-small would have 8/16-bit tokens while 32-large would have 32-bit tokens 19:52:20 the former is meant for systems where there is no conceivable way one could have more than 32768 words anyways 19:53:37 What kind of "words" are you speaking of? 19:54:17 Forth words, both primitive and non-primitive 19:54:39