00:00:00 --- log: started forth/19.01.01 00:17:23 --- quit: nighty- (Remote host closed the connection) 01:02:47 --- quit: dave9 (Quit: dave's not here) 01:03:07 --- join: dave9 (~dave@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth 01:04:05 --- quit: rdrop-exit (Ping timeout: 250 seconds) 01:08:31 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 02:04:18 --- quit: ashirase (Ping timeout: 250 seconds) 02:07:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 03:36:40 --- quit: pierpal (Quit: Poof) 03:36:58 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 03:39:27 --- join: proteusguy (~yaaic@49.230.15.155) joined #forth 03:39:27 --- mode: ChanServ set +v proteusguy 03:40:36 --- join: proteus-guy (~proteus-g@49.230.15.155) joined #forth 03:54:26 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:20:19 --- quit: proteusguy (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org) 05:07:09 --- nick: proteus-guy -> proteusguy 05:07:30 --- mode: ChanServ set +v proteusguy 06:14:58 --- quit: Keshl (Read error: Connection reset by peer) 06:15:20 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 06:28:12 --- quit: pierpal (Quit: Poof) 06:34:42 --- quit: Keshl (Ping timeout: 250 seconds) 06:46:21 --- join: Kumool (~Khwerz@adsl-64-237-236-36.prtc.net) joined #forth 06:48:28 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 07:10:44 nice - added unit tests - https://gitlab.com/lilo_booter/rpany/blob/master/tests/main.cpp (work in progress of course) 07:13:48 --- join: proteus-guy (~proteus-g@49.230.15.210) joined #forth 07:17:36 --- quit: proteusguy (Ping timeout: 250 seconds) 07:38:56 hm is there a secret to specifying hex numbers? 07:39:15 not all sources seem to use BASE 07:47:49 A lot of people here are anti standards, so if your forth doesn't follow any, that's just "the forth way" 07:50:13 fair 07:50:36 it's just a question how to handle it 08:14:34 hm, what should CREATE put in the code field for my DTC? 08:14:39 i mean, by default 08:18:37 or rather, do i have a doCREATE? 08:29:15 corecode: Some implementations use $ or 0x as a prefix for hex numbers. 08:29:39 corecode: typically if the forth does not recognize the token as a word, it checks if the digits form a number in the current radix and converts that to a literal. 08:29:39 ...or a character prefix for the number's radix $DEADBEEF 08:30:39 HEX and DECIMAL are ANS-standard, so you can do "HEX 10 DECIMAL ." and you'll get 16. 08:33:44 16#deadbeef 08:33:45 In one of the FORML proceedings someone was talking about defining words with wildcards in the word name 08:33:45 ...and then within the body of the word fetching characters from the word name and using them in the definition. 08:33:45 I think this would be a good way to implement radix prefixes. 08:34:43 that's interesting, but requires you to reserve some characters 08:35:15 i guess just one character for wildcard escape 08:36:37 There's plenty of unprintable characters. Many of the smallest ascii characters have no contemporary use. 08:37:58 (various control characters for dot matrix printers and whatever) 08:56:42 you mean for representation in memory? i mean for the human typing it 08:58:09 i have to be able to write, for example, : \*$\* ... which means \ has just become a reserved character that can't be used in words (unless you use like : foo\\bar ; and then call it with foo\bar) 09:01:34 One could also put an array of execution tokens ( referred to by the printable text) as well as the usual string literals in the word header. 09:01:35 It would be just regular compiled forth code to be attempted when trying to match a word. 09:01:35 The code would continue executing through the word body on the current level of specificity if the header reads true as a statement in English or else relax to a more vague natural-sounding statement ( Sam Falvo style forth https://docs.google.com/presentation/d/1Ko1EbK3FVLd6AldD9NIM5UUK_uQ07JZc9azAiDd2c6U/edit#slide=id.p ) 09:01:35 This is a way that actual forth code can be written by a water level or temperature sensor for instance. 09:01:35 http://www.forth.org/svfig/kk/11-2017-AWagner.pdf 09:10:50 zy]x[yz: I'd like to be able to create definitions without any punctuation by way of something like https://en.wikipedia.org/wiki/Mill's_Methods + memoization. 09:11:33 It's just a bit too hazy for me to implement now. 09:38:16 I think we should start writing every language C style 09:38:20 C style Clojure 09:38:24 C style Haskell 09:38:33 C style Prolog 09:38:37 C style Forth 09:38:55 Not being like C hurts adoption and so is a bad thing for old fogies living in the past 09:40:27 but C is legacy programming language! 09:43:09 If you're not plastering your code with local variables you're barely even programming 09:46:46 locals are too trendy. 09:47:28 Something i always find weird 09:47:36 people who check for things their program isn't going to do 09:51:05 WilhelmVonWeiner: can you expand on what you mean, please? 09:53:16 "Add two numbers: check the humidity in the room, first" 09:54:20 When you write a program, best check for everything and anything. 09:54:35 Users are stupid and might break stuff when you don't sanitize everything and anything. 09:55:20 Students and other academics will break stuff even more easily because they will wonder "wether X will break the system" and then your system falls apart. 09:55:47 And when the system is exposed to the internet in any way, people will constantly scan for vulnerabilities. 09:56:20 I had to change ssh to a non-22 port because people kept spamming my (pubkey-protected) ssh server with requests. 09:56:48 I'm not talking about sanitised input in this instance 09:56:54 I can understand sanitised input 09:57:25 but sometimes application code is error checking things that won't go wrong, or protecting the user from themselves in situations where both of your lives are easier by restarting the program 09:58:05 john_cephalopoda: yeah, I ran an sshd emulator on a 22 port for years. With slow loris (though I didnt know it was called that at the time) buffering 09:58:26 Zarutian: Within days I had several MB of ssh logs. 09:58:37 Also if you're running your Forth program on Linux or BSD the kernel is protecting everything anyway and you shan't really have to worry 09:58:46 not *everything* but you get my point 09:59:03 Also my web server... Pretty exactly 1/3rd of the request strings contain the substring "php". 09:59:15 WilhelmVonWeiner: aah, yes. Some such checking is quite pointless. 09:59:45 I got no php installed. Some botnets just look around and try out paths like "myphpadmin/". 10:00:37 Reminds me of a Jeff Fox story where he replaced a bunch of ANSI-style try/escape, check/throw style error checking and correction code with 2DROP 10:00:56 always makes me chuckle 10:02:32 well, I use check/throw style for checking errors but only to stop, report it intelligently to the user "oh, that spefic file needed for this task is non-existant" etc 10:02:50 That's a reasonable usage ofc 10:03:36 but trying to correct for some strange error with such? naah 10:56:55 --- quit: rdrop-exit (Quit: Lost terminal) 11:00:33 so do you implement : with CREATE? 11:02:20 I implement : and CREATE using a shared primitive which makes a dictionary header from a provided string 11:02:59 --- quit: gravicappa (Ping timeout: 250 seconds) 11:11:31 TIL about the #gopherproject irc channel 11:25:19 well, if anyone ever figures out how to download http://chiselapp.com/user/tehologist/repository/compc/home - let me know ;-) 11:26:11 http://chiselapp.com/user/tehologist/repository/compc/tarball/6a69773d2c/CompC-6a69773d2c.tar.gz 11:28:24 Got it, thanks... I dunno wtf that web format was all about 11:32:24 --- quit: dddddd (Read error: Connection reset by peer) 11:32:33 That's a fossil repository, you can grab snapshots by going to the timeline and selecting a commit 11:34:41 ah.. Yeah, squid was telling me it was something weird for SVN - I saw fossil - but.. Just weird. 12:35:08 --- quit: Kumool (Remote host closed the connection) 12:40:41 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 12:44:43 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 12:47:56 --- quit: MrMobius (Ping timeout: 246 seconds) 12:47:56 --- nick: [1]MrMobius -> MrMobius 13:03:51 --- join: Kumool (~Khwerz@adsl-64-237-236-36.prtc.net) joined #forth 13:20:16 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth 13:20:37 hi 13:23:34 proteus-guy: check yer pm 13:32:29 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 13:53:06 --- nick: proteus-guy -> proteusguy 13:53:31 proteusguy: use that link as you like. 13:54:02 --- mode: ChanServ set +v proteusguy 13:54:38 PoppaVic, sorry perhaps my irc burped... I don't see a link. 13:54:51 KipIngram: I gotta' admit, yer right: It's changed here for the better 13:55:10 proteusguy: in the PM and then email. 13:55:24 In any case, it clarifies 13:56:03 One of my huge issues with forth is the HEADS - commonly embedded, often inline, and it's wrong. 13:56:38 We got too many smart people to blindly accept that silliness. 13:57:28 ah got it - thanx! 13:58:26 pointfree: Huh, what's #gopherproject about? 14:10:54 --- quit: mtsd (Quit: WeeChat 1.6) 14:13:23 back 14:13:59 tabemann: proteusguy went to bed. Sorry, Have fun. 14:19:43 I've got a stupid question 14:19:52 what's the best way to create two different CREATEd words at once 14:20:04 well wait 14:20:05 I've got it 14:20:13 it's nonstandard, but fuck standards 14:21:32 what's CREATE doing for you? 14:27:54 I'm working on an assembler for hashforth 14:28:49 and I'm trying to create two words - one which directly compiles the word, and one which returns the token for the word on the stack 14:29:25 like .FOOBAR and &FOOBAR 14:30:15 it's not a very typical assembler, because the code for it looks more like plain Forth than normal assembly would 14:32:21 tabemann: do you compile the token into whatever thing that the compilition word is being immediately called for? 14:32:43 yes 14:33:05 it's pretty simple really, it's just not something that ANS can do 14:33:28 then have the token returning word be defined first then the compiling word be defined. 14:33:59 * PoppaVic chortles 14:34:02 the main thing is I need to be able to create a word with its name being specified programmatically at runtime 14:34:27 I called my word to do this CREATE-WITH-NAME ( c-addr u -- ) 14:34:31 tabemann: you using TIB and co? 14:34:40 TIB and co? 14:34:43 ah okay 14:34:52 Terminal Input Buffer 14:35:13 I've got a word named PARSE-NAME that grabs a string out of the TIB 14:35:40 but if you have create-with-name that takes an string like that then you dont have to save the tib pointer and length like I was going to suggest 14:42:21 : BLE ( token-id -- ) PARSE-NAME 2DUP CREATE-WITH-NAME HERE SWAP , DOES> @ EXIT R str:PREPEND & CREATE-WITH-NAME R> , DOES> @EXECUTE , ; \ or some such 14:42:46 BLE is a 'reserved name" ;-) 14:43:07 s/BLE/arghblargh/ 14:43:38 --- quit: pierpal (Quit: Poof) 14:43:50 naming things is often the hardest part in programming. 14:43:55 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 14:45:03 back 14:58:38 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 15:00:56 Zarutian: I disagree. (but you knew I would) 15:03:29 --- quit: tabemann (Ping timeout: 250 seconds) 15:07:39 Zarutian: agreed - names are always difficult - what makes sense to me may be interpreted in a subtly different way by someone else 15:08:01 and it's the subtle differences which are the killer 15:13:00 Again, I disagree.. noun|verb, adjective... It's only when all tossed to the flat Namespace you get confused. 15:23:26 :) - philosophical point i guess... but we all have flat (or indeed, heirarchical) namespaces which we carry in our heads - and they're all subtly different 15:24:16 some of those differences are just down to misunderstanding, some are down to experience 15:24:54 language is personal from a human perspective - very imprecise 15:25:07 what's the stack comment for a word that ticks? 15:35:17 "name" -- xt 15:36:07 (from dpans94, for ' ) 15:40:28 thanks. 15:46:48 --- quit: pierpal (Quit: Poof) 15:47:04 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 16:14:33 --- quit: john_cephalopoda (Ping timeout: 250 seconds) 16:16:27 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:18:31 --- quit: pierpal (Ping timeout: 246 seconds) 16:47:17 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 16:47:43 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 16:49:46 Nobody ever told me colorForth doesn't include create does 16:55:53 omg, it's the end of the world 16:59:40 does it include It's not necessary for a Forth to have DOES> 17:00:49 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 17:01:45 I'd say DOES> is more necessary than CREATE 17:01:50 It's somewhat superfluous in a native code Forth 17:01:51 is CREATE STRUCTURE equivalent to : HERE! POSTPONE HERE ; IMMEDIATE : STRUCTURE HERE! ; or am I missing something 17:02:00 if not then I can see how you can do without it 17:02:03 because much of the functionality of CREATE can be replaced by e.g. some embedded forths lack CREATE because it complicates compiling code to flash 17:02:56 whereas so you're not writing flash twice 17:05:30 * PoppaVic chortles 17:07:01 explain the chortle 17:07:23 (I notice you're a fan of chortling) 17:08:43 What do you mean "more necessary"? I said it was not necessary. 17:09:09 Yes, it's akin to a chuckle, and similar to a rotfl, but much more stomach/diaphragm-related 17:09:20 okay, but why 17:09:55 Yes, rdrop-exit - why? ;-P 17:11:20 PoppaVic: you /me chortles, why? 17:11:58 WilhelmVonWeiner: it's a natural reaction to the insane and inane - and it saves lives. 17:12:10 Again, not an answer to the question 17:12:19 Yes, I noticed ;-) 17:12:36 the thing is I still don't know what you were chortling in response to and why 17:13:11 tabemann: the man that overcomplicates the universe, worried about over-flashing? 17:13:15 * PoppaVic chortles 17:13:15 chortles aren't very informative and thus aren't very helpful 17:13:31 * zy]x[yz cackles 17:13:42 * PoppaVic nods to zy]x[yz 17:13:46 just a bit smug 17:13:54 well overflashing is bad because it reduces the lifetime of your device 17:14:00 this is a given 17:14:11 * WilhelmVonWeiner weeble wobbles but I don't fall down 17:17:57 what is your guys' opinion of writing a limited version of Forth with a VM image, and then using that to bootstrap a full, actually usable version of Forth that is compiled from source? 17:19:48 "compiled from source" meaning a single c-style binary? 17:20:42 no, I mean implement a mini-Forth with the hashforth assembler, and have that mini-Forth bootstrap the full Forth which is written in Forth source coded 17:20:44 *code 17:21:04 it would not compile to a single C-style binary 17:21:29 sounds like what Retro is 17:21:42 rather there would be the mini-Forth image, which contains VM instructions, and the Forth source, which is in Forth 17:22:01 It's the Nga VM which boots the Rx kernel which runs undernearth the RetroForth system 17:22:44 the main difference here is that the mini-Forth is essentially a throw-away - it will be discarded once the full Forth is bootstrapped 17:23:49 interesting 17:23:51 Are you speaking of the VM processor we were discussing earlier? Or of cross-compilation? or meta-compilation? 17:24:06 rdrop-exit: the latter from what I gather 17:25:02 if it's faster go for it 17:25:17 In Meta-compilation you use your current Forth to compile a new version of itself. 17:26:51 In cross-assembly and cross-compilation you use your Forth to generate code for another target. 17:27:50 back 17:28:03 I'm doing cross-assembly 17:28:18 Ok 17:28:26 I wrote an assembler for attoforth to generate an image compiled of VM instructions for hashforth 17:28:52 What VM are you targeting? 17:28:58 hashforth 17:29:48 Hashforth is a VM? 17:32:14 yes 17:35:34 Ok, then you generate a target memory image, place it somehow in your VM's memory, and then boot up you're VM, which presumably jumps either directly or indirectly to a boot address, and then you're off to the races. 17:36:10 * your VM, not you're VM 17:39:00 yes 17:39:15 The underlying VM might be implemented as software, or a soft core on an FPGA, or as real HW. 17:39:28 yes 17:40:23 about placing it in the VM's memory, I wrote a relocating loader which relocates the image to wherever it is loaded into memory 17:42:40 Keep in mind that there's probably a fixed reservfed area of memory for vectors and such. 17:42:43 the images themselves are crossplatform as long as the cell size, endianness, and token type (8/16, 16, 16/32, or 32) match 17:43:54 The images just target the VM, it's the VM that is cross-platform. 17:44:04 yes 17:45:17 If you wanted to you could have multiple VMs, one for each cell size, and the image would target that particular VM/cell-size combination. 17:45:26 I've designed the VM implementation so it can be compiled for any of 16, 32, or 64-bit cells and 8/16, 16, 16/32, or 32-bit tokens without other modification 17:46:16 the only catches is that the assembler produces the endianness of the machine it was run on 17:46:23 *catch 17:46:58 even though that could easily be changed 17:47:56 You're going to run into the same issues as the standard if you make it all cell-size independent. 17:51:24 It makes more sense to me to have a trio of VM implementations, e.g. 16-bit, 32-bit, 64-bit. 17:52:42 I could split up the VM implementations if trying to make them cell size-independent proves problematic 17:52:55 but at the moment I haven't run into any hitches 17:53:20 If the VM can be implemented as HW, the cell size is the cell size. 17:53:23 brb 17:55:57 back 17:56:28 --- quit: dave0 (Quit: dave's not here) 17:57:03 --- join: presiden (fwiw@unaffiliated/matematikaadit) joined #forth 17:57:22 It all goes back to the initial assumption that the VM can be implemented in either SW, firmware, FPGA, HW or even a steam engine. :) 17:58:21 The cells and the stacks of a VM instance are a particular bitwidth. 17:59:50 yes 18:00:09 all I did is make those selectable at compile-time 18:01:00 Compile-time of what? 18:01:12 * tabemann wonders about the idea of executing forth on a difference engine 18:01:22 at the time that the VM written in software is compiled 18:01:59 The code of a SW implementation of the VM, or the code you're going to run atop the VM? 18:02:01 hm, how do i implement POSTPONE 18:02:12 so you can do make CFLAGS="-DCELL_16 -DTOKEN_8_16" 18:02:25 rdrop-exit, the code of a SW implementation of the VM 18:03:18 no, I wasn't suggesting that cell size could be selected when the Forth code would be compiled - that'd be silly 18:03:36 Ah, I see the code of a C-based implementation of the VM. 18:04:06 tabemann: it is boring, the wheels just go forth and not back 18:04:21 lol 18:04:43 Each VM implementer can use whatever tools and methods he likes, as long as the resulting VM implements the spec. 18:04:46 like, how do i append the compilation semantics of a normal (non-immediate) word? 18:04:56 corecode: 18:05:10 something with (LITERAL) and COMPILE,? 18:05:25 this is what attoforth does: 18:05:26 =COMPILE,-16-32-LO 18:05:26 .BRANCH-FORE =COMPILE,-16-32-END 18:05:32 whoops 18:05:45 ": POSTPONE ' DUP IS-IMMEDIATE IF " 18:05:45 " COMPILE, " 18:05:45 " ELSE " 18:05:45 " COMPILE (LITERAL) , COMPILE COMPILE, " 18:05:45 " THEN ; IMMEDIATE COMPILE-ONLY " 18:06:38 what's the difference between COMPILE, and , ? 18:07:47 Mine is: 18:07:58 : & { -- } ( -- ? ) 18:07:59 compilation defined 18:07:59 dup immediate? if >code compile, then; 18:08:00 >code & literal & compile, ; directive 18:08:53 then; is then + ;? 18:09:21 Kind of, yes 18:10:41 My equivalent is: 18:10:44 :prefix:| 18:10:44 d:lookup [ d:xt fetch ] [ d:class fetch ] bi 18:10:44 compiling? [ [ class:data ] dip compile:call ] 18:10:44 [ call ] choose ; immediate 18:10:56 Whenver possible I avoid ELSE 18:11:11 why? 18:11:24 This is one way 18:12:04 Because at that point in the code, the job has been done and control returns to the caller 18:12:50 COMPILE, and , are the same on ITC systems 18:13:09 tabemann: thanks 18:13:24 that makes sense 18:13:34 on other systems, that have to compile code into native code/subroutine calls, or TTC systems, where the token size doesn't match the cell size, they are different 18:13:36 that hels to distinguish things 18:14:06 like in hashforth COMPILE, and , are different, because cells may be 32-bit while tokens may be 8/16-bit 18:14:18 as likely would be common on smaller ARM systems, e.g. 18:16:15 I thought we had settled on bytecodes for the VM. 18:17:07 Up to 256 opcodes, all one-byte wide 18:18:45 I'm unifying the opcode and word representation; sure, if the implementation wants to separate the two internally that's fine (which would be the case with a JIT turning the TTC code int NCI/SRT code) 18:19:15 I have no idea what you mean 18:19:42 what I mean is that in the code format the user sees there aren't CALL opcodes 18:20:30 user? You're trying to hide things at the level of the processor design? 18:21:21 Shouldn't we first design the processor, before you start hiding things from the users? 18:21:31 the user has access to the format of the code as it is compiled prior to the execution of j 18:21:34 whoops 18:21:35 ; 18:21:45 nah, if you hide them now, we'll never find them later 18:22:24 We're spec'ing out a machine, there's nothing to hide at this point. 18:23:15 what I mean is that CALL opcodes are more appropriate for when the code has been converted into SRT/NCI internally by the VM 18:23:26 key word is internally 18:23:48 just like how code written in Java doesn't have access to the JITed code generated by the JVM 18:23:57 all it sees is bytecode 18:24:46 The analogue of written Java for us, is written Forth. 18:25:16 Java has source and bytecodes, we have source and bytecodes. 18:25:33 Our bytecodes are the opcodes of a VM ISA. 18:26:24 What is the JAVA analogue of your other tokens? 18:28:59 The Java analogue of our Forth VM is the JVM. 18:30:31 I'm not understanding this extra layer of tokens you're proposing. 18:30:32 ah, either I am prematurely abstracting or you are prematurely optimizing - lol - anyways, as I envision a JITed VM (even though my current hashforth is not JIT-based), so it seems more worthwhile for the forth binary format to be more abstract, and to move the implementation details into the code generated by the JIT 18:32:02 JIT is an implementation option for translating and executing the JVM bytecodes. 18:33:02 Right now we are spec'ing our analogue to the JVM, I suspect you are doing both premature abastraction and premature optimization. 18:33:50 I thoroughly disagree with the use of a call opcode - it's a horrible waste of bits on small systems - but as I've said before, I might agree to a call bit 18:35:10 tabemann: I read a really nice idea in an other channel. 18:35:12 The call opcode falls out from our decision to use bytecodes, one of those bytecodes, let's say 0x01 is call. 18:35:41 tabemann: Instead of using weird opcode magic to do absolute JMPs, just push an absolute address to the return stack and then do RET :D 18:36:09 rdrop-exit, the call opcode means that, on a 16-bit system, each call is in total 24 bits 18:36:23 on a 16-bit system that's an unforgivable waste of bits 18:36:34 Not necessarily 18:37:57 with a call bit you get it down to 16 bits, with the restriction that words cannot start in the 256 lowest bytes of memory and words have to start on even addresses 18:38:44 I thought we had already settled on bytecodes, are you saying you don't want bytecodes? 18:39:02 I remember us discussing call bits as an option 18:39:21 Sure but the two don't really mix 18:40:50 think about it this way - my hashforth, which probably has more opcodes than necessary, doesn't even get close to using 128 opcodes 18:41:14 so you're wasting bits by allocating a full byte to just the opcode 18:41:27 think about processor architectures 18:41:52 in most processor architectures a full byte is not dedicated to the instruction itself (as opposed to registers, immediates, and like) 18:42:36 Remember the instruction cycle of the processor is a bottleneck 18:42:40 the only reason I see to allocate a full byte to the opcode is to speed up the decode 18:43:26 e.g. you might want an indirect fetch instruction @@ instead of using two cycles for "@ @", etc... 18:44:16 You'll probably end up using close to the 256 instructions 18:44:50 Also you'd probaly want multiple LIT instructions 18:45:34 e.g. -1 0 small integers, inverted lits, etc... 18:46:30 You will likely implement frequently used combinations of words as opcodes 18:46:54 to lessen the bottleneck effect 18:47:38 Things like @+ !+ etc... 18:49:08 Some math functions e.g. log2 18:49:57 Some bitwise functions, e.g. Hamming Weight, etc... 18:50:23 back 18:50:26 you guys have simply bizarre ideas of "core" and "minimal" 18:50:32 umm rdrop 18:50:50 doesn't that go along with what I had planned with tokens 18:51:04 that the hardware could transparently implement any particular thing 18:51:14 without the software having to see a difference 18:51:41 whereas you're planning on baking all these things into what is intended to be a hardcoded instruction set in hardware! 18:51:41 That's the compiler's job not the hardware's job 18:51:56 an instruction for hamming weight! 18:52:10 aside for some specialized DSPs, it's hard to envision such a thing 18:52:35 I'm not syaing you need these things, I'm saying you need to settle on the ISA before you go off in a bunch of other directions 18:53:24 I'm not advocating particular instructions, I'm saying one of the first steps is to settle the ISA 18:54:29 Obviously if you're designing a chip, whether real or virtual, you settle the ISA 18:56:25 by "settle" I'm sure you mean "determine what we should probably try first completely prepared to abandon and do something completely different based on the experience", correct? :-) 18:56:49 I thought we had settled on a fully encoded bytecode format, if not them I guess we need to step back and settle the format 18:57:00 Sure, plan to throw away 18:58:01 So my question is, are we settled on a bytecode format, or not? (for our first iteration attempt) 18:58:16 no, we're not settled on a bytecode format 18:58:35 so I would imagine whomever is stepping up to write a sample prototype would have significant influence on the proposed ISA that he or she is implementing. 18:58:53 which is what I'm doing 18:59:26 * proteusguy understands and is interested in any such attempts even if they're counter to my initial intuition. :-) go forth and #forth! 19:00:05 Cool 19:03:11 proteusguy: What was your initial intuition? 19:03:31 * proteusguy has about 12! ;-) 19:03:59 We're here to chat, go ahead :) 19:04:24 but it's honestly more along the lines of concern of too much complexity too soon and not certain it's justified. often that can only be determined by working through it and discovering at the end. so I fully support tabemann 's efforts. 19:05:18 Me too 19:05:33 also I look at how I might implement such a thing on an fpga so that colors my intuition. I also understand that's NOT tabemann 's primary concern which is completely fine with me. 19:06:09 part of the difference between me and rdrop seems to be that I am envisioning a software implementation, with practical implementations using a JIT whereas rdrop is envisioning FPGA or ASIC implementations as being the primary targets 19:06:25 tabemann, yep I got that from yesterday. 19:06:36 I didn't identify any primary target 19:07:23 I've said all along that it should be implementable as SW, firmare, softcore on FPGA, and HW 19:07:35 tabemann, let's just say I don't think I have any more concerns about your method than I would any other "good" ideas. they would just be different. naturally every solution has its tradeoffs. I completely support your efforts and am excited to see results. 19:09:00 * tabemann amused by the fact that he got his assembly to look awfully like Forth 19:09:16 WORD SEARCH-WORDLIST ( c-addr bytes wid -- xt found ) 19:09:16 .WORDLIST>FIRST +BEGIN 0 .LIT .<> +WHILE 19:09:16 2 .LIT .PICK 2 .LIT .PICK 2 .LIT .PICK .WORD>NAME .COMPARE-NAME +IF 19:09:16 .ROT .ROT .DROP .DROP -1 .LIT .EXIT 19:09:16 +THEN 19:09:17 .WORD>NEXT 19:09:18 tabemann, that's a good sign I think. 19:09:21 +REPEAT 19:09:23 END-WORD 19:09:30 Me too, don't let me discourage you, I'm just trying to grok what you're proposing 19:09:43 tabemann, what are you implementing your solution on top of? 19:10:31 my initial implementation is initially written in C, because it makes for more understandable and portable code, and allows for things like selecting cell size at compile-time 19:10:44 a practical implementation would probably be written in assembly for the target arch 19:10:47 cool 19:11:34 right now what I'm working on is the VM image that the implementation loads initially, which is written in VM instructions 19:13:14 * proteusguy is randomly implementing his language solutions in AMD64 ASM, python, and C++ depending on which problem he's trying to solve. Right now playing with a type system and parser in python. 19:14:39 has anyone written to Dr Ting of eForth and gotten back a reply? I've written him asking about his FPGA implementation but still no answer. probably on holiday still. 19:22:07 more and more I think I'll just get popcorn 19:23:54 PoppaVic, do your own man! :-) Submit it as an option. 19:24:20 \Well, my popcorn is simple 19:24:30 PoppaVic, all the better. 19:25:55 even if it's an existing solution - always happy to have an implementation example that we can have useful comparisons with. Helps to demonstrate costs of trade-offs and complexity. 19:27:46 How about we just use one of Chuck's chips? 19:27:57 doesn't even have to be one that one of us wrote. just needs to be one that someone knows intimately so they can answer critiques and questions at an expert level. submitters need to be able to stand by it so the comparisons are useful and valid. 19:28:22 rdrop-exit, would love it if one of us knows it well enough to be able to design it again. 19:28:23 rdrop-exit: easier to just pour a drink. Play on. 19:29:30 His ISAs are very simple 19:29:54 In my strongly typed actor model forth-ish language I certainly have the greenarrays multi core chips as a potential interesting target to see what the real computation/power/speed ratios are. 19:30:27 --- quit: dddddd (Remote host closed the connection) 19:30:41 rdrop-exit, many complex ideas/principles lie behind SIMPLE designs. That's the definition of elegance. 19:31:17 I'm all for simplicity 19:31:33 as simple as possible but no simpler. :-) 19:36:37 Although if you're targeting a Chuck chip-like VM, you should just ignore ANS/2012, which is fine with me 19:38:37 back 19:41:12 The 32 opcodes of the F18A: http://www.greenarraychips.com/home/documents/greg/PB003-110412-F18A.pdf 19:45:09 brb 19:45:33 I've got a question 19:45:38 is SOURCE an ANS thing? 19:45:48 yes 19:45:56 what do non-ANS forths do? 19:46:12 I know there's TIB 19:46:22 but how do they expose the *length* of the buffer's data 19:46:31 Depends on the Forth 19:46:45 what should we do 19:47:06 That's far above the concers of the VM 19:47:08 That's at a higher level than the ISA 19:47:16 I'm not writing this into the VM 19:47:18 * concerns 19:47:23 I'm writing this into the image the runs on the VM 19:47:39 the VM knows nothing about this 19:48:46 so what would you do? 19:49:37 My Forth doesn't have SOURCE. I have a standard TIB buffer reserved between the kernel and the start of the standard library. The interpreter takes a string pointer to a single token, it doesn't have to be in the TIB. 19:50:29 rdrop-exit, I think EVERYONE agrees we're pretending ANS never existed. 19:50:40 Ok 19:51:54 I don't have source either 19:52:20 Well I have a word named "source" but its unrelated 19:53:35 I have a some words that I revector depending on whether input to the outer interpreter is coming from the user terminal or a block 19:54:04 Input from the console terminal goes to a TIB 19:55:43 I know there's TIB and #TIB 19:55:47 My TIB related words are non-standard, e.g. : drain ( -- +n ) tty tib #tib read dup retain ; compiled 19:55:52 : drain ( -- +n ) tty tib #tib read dup retain ; compiled 19:55:57 etc... 19:56:27 what I'm concerned about is that I'm gonna write parsing words now, and I need to know what the consensus is on how to handle them 19:56:46 e.g. does TIB and #TIB also cover file input and such? 19:57:12 My source comes from blocks 19:57:17 tabemann, doubt that any consensus would be arrived at so soon. 19:58:05 we've talked about streaming i/o input as definitely being in the standard and some minimal form of blocks as being likely. 19:58:24 I can have input coming from keyboard, file, or blocks 19:59:01 can TIB cover input from file or blocks, or does it only cover input from the keyboard? 19:59:06 I'm only keyboard and blocks 19:59:19 Depends on how you choose to implement it 19:59:20