00:00:00 --- log: started forth/19.01.27 00:11:15 --- quit: smokeink (Remote host closed the connection) 00:11:37 --- join: smokeink (~smokeink@42-200-167-113.static.imsbiz.com) joined #forth 00:21:30 any idea what ALIGN-BYTES and NHEADER do ? https://github.com/rufig/spf/blob/master/devel/~af/lib/langstrings.f#L13 00:33:46 oh I found something \ we should align to 16 (default value for ALIGN-BYTES) 02:00:21 NHEADER probably lays down a definitions dictionary header, just guessing 02:02:28 ALIGN-BYTES looks like a global where some sort of alignment default is stored. 02:02:29 yeah I kinda understood what it does https://github.com/rufig/spf/blob/90cc85c92f002bc7dd93077de41b7d97aa5de79d/devel/~af/lib/nwordlist.f#L22 (not 100% but enough for me to get an idea of the general mechanism) 02:03:07 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 02:03:18 what about +NWORD ? 02:03:28 --- quit: ashirase (Ping timeout: 244 seconds) 02:03:30 does it add a word into the current wordlist ? 02:04:05 I assume 02:04:54 Is there no documentation, or is it all in Russian? 02:05:01 --- quit: proteusguy (Ping timeout: 244 seconds) 02:05:25 for this functions I don't there's much documentation 02:05:50 *these 02:06:08 no documentation.. for these utilities 02:06:42 so one has to learn them the hardcore way, which is good in a way 02:07:08 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:07:54 Life's too short, there should be at least a one-liner for each definition 02:15:17 morning Forthniter 02:16:49 Good evening presiden 02:48:02 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth 02:48:02 --- mode: ChanServ set +v proteusguy 03:31:59 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:55:13 is there a way to check if a word by the name S" MYWORD" already exists in the dictionary in order to avoid it's recreation/replacement ? 04:04:43 You can search for it using FIND or something similar before adding it. 04:05:29 Some Forths emit a warning when you're reusing a name. 04:07:28 --- join: gravicappa (~gravicapp@h109-187-37-22.dyn.bashtel.ru) joined #forth 04:08:01 It's ok to have multiple definitions with the same name, sometimes that's exactly what you want, e.g. vocabularies. 04:09:05 ok 04:09:48 is there any standard inbuilt word that can convert a ( str u ) to a counter string ( cstr ) ? 04:11:06 You mean to a C-like zero terminated string? 04:11:56 FIND needs a string like the one returned by BL WORD MYWORD 04:12:14 BL WORD MYWORD FIND works, but S" MYWORD" FIND doesn't 04:12:40 so I have to convert what's returned by S" MYWORD" to something that FIND understands 04:13:09 Ah, you mean a counted string address, you'd have to copy the string somewhere and use that address. 04:13:59 ok, I just realized I can just use BL WORD MYWORD FIND directly in the sourcecode file 04:14:53 Let me check the standard FIND 04:15:23 no need for S" " BL WORD MYW FIND works... 04:16:10 right 04:18:10 I don't follow the standard when it comes to dictionary search, I don't have a FIND. 04:19:59 on your retroforth ? 04:20:56 pointfree: You keep up with clf and SVFIG right 04:21:14 No, don't know retroforth, have my own Forths. 04:21:51 rdrop-exit: do your forths run on linux or windows? 04:22:55 My umbilical host is POSIX. I don't do Windows. 04:23:34 ok 04:37:28 http://www.complang.tuwien.ac.at/anton/euroforth/ef98/milendorf98.pdf 04:37:55 handler @ >r ( xt) \ Save previous handler 04:37:55 rp@ handler ! ( xt) \ <- isn't rp@ getting the value which was just put on the return stack?? 04:39:27 rp@ is the address of that value 04:40:00 You're thinking of r@ 04:40:07 oh 04:40:24 thanks 04:40:33 Sure 04:41:17 rp@ is getting the value of the return stack pointer "register" 04:41:56 : R@ R> R> DUP >R SWAP >R ; \ if you are curious 04:42:34 Albeit r@ is usually implemented as a primitive. 04:43:09 I prefer the Chuck-style name TOP instead of R@ 04:45:30 as well as POP instead of R> 04:45:30 --- quit: dddddd (Ping timeout: 250 seconds) 04:45:38 PUSH instead of >R 04:45:48 COPY instead of DUP >R 04:47:24 rdrop-exit, same here - except lower case. ;-) 04:47:53 case sensitive or insensitve? does it matter much? 04:48:09 Me too, only lower-case, just using upper because there's no bold in IRC 04:48:29 bold 04:48:30 My Forths are case-sensitive 04:48:45 How'd you do that??? 04:49:06 ctrl-b sometext ctrl-b 04:49:12 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:49:19 ctrl-b just inserts a byte with the value 2 04:49:20 testing 04:49:33 Cool! Thanks! 04:50:07 italic 04:50:13 underline 04:50:37 Not showing up as italic on my terminal, underline is ok though 04:51:07 https://modern.ircdocs.horse/formatting.html 04:51:52 Thanks 04:51:59 9 green 04:52:03 works 04:52:05 http://www.ircbeginner.com/ircinfo/colors.html 04:52:47 Although none of this will show up properly in the IRC logs 04:52:54 (I assume) 04:54:49 I disable italics and bold 04:54:55 Your "green" shows up as "9 green" in the logs 05:06:03 WilhelmVonWeiner: Why do you disable those? 05:06:43 --- quit: pierpal (Remote host closed the connection) 05:07:33 I can see the need for disabling colours. Those add little to nothing to the experience, but italic and bold seem decent without being a distraction. 05:16:58 Because I can't barely read bold with my 10px monospaced terminal font 05:17:09 in Emacs and Acme my fonts are bold by default 05:48:00 --- quit: smokeink (Quit: byebye) 05:59:31 hi 06:00:21 my forth cpu can push literals and add :) 06:01:21 https://github.com/corecode/forth-cpu 06:01:29 probably it can do more, but i didn't try yet 06:11:17 corecode, nice going! pretty clean verilog. you done stuff with verilog before? 06:12:03 some 06:12:19 but i am not afraid of throwing away code and starting again 06:12:37 until it feels idiomatically correct 06:13:14 i'm not sure about my using the combinational signals (*_next) all over the place, instead of using the registers 06:13:26 I'm wanting to use MyHDL to create my verilog so I can code in a more expressive language. I'm not much good at verilog but your code seems fairly easy to follow so that's a good thing. 06:13:28 but using the registers would delay everything by a clock cycle 06:13:50 add unit tests! :-) 06:14:06 yea i had a pretty good idea what i wanted it to look in hardware 06:14:24 if i just think of what its behavior should be, the code gets more convoluted 06:14:44 yea, that's the next thing. testing every opcode for desired side effects 06:15:12 I'm a little confused 06:15:23 why do you need a "next" for everything 06:15:29 can't you just set it? 06:15:43 that's not how hardware works 06:15:59 you have a set of boolean logic that produces a value 06:16:18 and you have a register that takes this value and stores it, at a clock edge 06:17:15 basically you can just "set" at discrete times (clock edge) 06:17:21 well yes 06:17:26 not sure i'm making it clearer 06:18:14 maybe if you ask in a different way i can explain my reasoning better 06:18:43 Don't worry about it, I don't think I can explain in your terms what I think is wrong 06:18:51 or not wrong but like 06:19:04 you know what I mean 06:21:02 Looked at the J1 source, I get it 06:41:06 Your NOT op should be using ~ rather than ! 06:42:19 yes, thank you 06:42:37 i wonder what ! does to a vector? 06:42:50 boils it down to 1 bit 06:44:31 it does an or reduction first 06:51:56 then the result wouldn't match the width 06:51:57 hm 06:53:45 i with icarus verilog had more warnings 06:53:54 maybe i should try verilator as well 06:55:05 It would be leading zeros then a 1 06:55:55 Is there a reason your keeping the TOS separate from the rest of the stack? 06:58:41 Do you plan on putting your stack outside the core? 07:00:58 If this is for an FPGA your whole stack can be a register file 07:01:06 in the core 07:02:05 Both stacks 07:04:16 Gotta go, good night all. Keep on Forthin' 07:04:31 --- quit: rdrop-exit (Quit: Lost terminal) 07:05:52 i found a bug in my code :-( 07:07:13 i tried to do return-stack words like : r@ r> dup >r ; but i forgot that calling words uses the return-stack too 07:08:18 must i make words that twiddle the return stack primitives? 07:09:11 WilhelmVonWeiner: I go to most SVFIG meetings. I was just at one yesterday. I don't read very much of clf. 07:12:21 Do you know if Ting plans to release source to his ESPx eforths? 07:16:32 He probably would, I could ask him. 07:19:41 dave0: twiddle? 07:21:06 corecode: i think it means change something aimlessly :-) 07:21:35 you might twiddle a knob by just winding it back and forth for no reason :-) 07:21:45 just cos it's nice to play with knobs heh 07:23:34 i don't know what you mean 07:23:41 it's pretty simple 07:25:14 : R@ ( -- x )( R: x ret -- x ret ) R> R> DUP ( ret x x ) ROT SWAP ( x ret x ) >R >R ; 07:25:33 or you implement R@ as code 07:25:48 R@ is R> DUP >R 07:26:07 WilhelmVonWeiner: only if it isn't a word 07:26:18 immediate? 07:26:36 immediate would use the compiler r-stack 07:27:06 unless you mean : R@ POSTPONE R> POSTPONE DUP POSTPONE >R ; IMMEDIATE 07:28:21 not sure how that would then work with POSTPONE R@ or ['] R@ EXECUTE 07:28:27 WilhelmVonWeiner: that's what i had for R@ except that i forgot the actually calling the word puts the return address on r stack aswell.. so r@ r> dup >r actually copies the return IP to the data stack, not the value at the top of the stack, like i expected 07:29:56 I'd never really thought about it 07:29:57 sorry s/r@// 07:32:11 you're right corecode 07:33:38 : R@ R> R> SWAP OVER >R >R ; if you don't have 2R> and 2>R 07:34:05 ah swap over, that's better than mine 07:34:22 TUCK even 07:34:33 all these luxury words 07:35:31 hm, in the shower this morning i thought about VARIABLE creating an immediate word 07:36:26 instead of doing the indirect dovar thing 07:36:35 i'm sure i'm missing something 07:56:49 --- join: xek (~xek@apn-31-0-23-82.dynamic.gprs.plus.pl) joined #forth 08:10:16 --- quit: nighty- (Quit: Disappears in a puff of smoke) 08:35:19 --- quit: dave0 (Quit: dave's not here) 10:31:48 --- quit: gravicappa (Ping timeout: 240 seconds) 11:03:19 about the above, you could make a CONSTANT that compiles a true constant word rather than doing the CREATE .... DOES> @ thing 11:05:08 : CONSTANT : POSTPONE (LIT) , POSTPONE ; ; IMMEDIATE might work 11:07:26 In my forth variables compile code to push the address to the stack. Same thing with constants (they compile code to push their value to the stack) 11:08:32 in hashforth I'm using the traditional CREATE and CREATE ... DOES> mechanisms 11:10:12 :var d:create >0 , ; and :const d:create d:last d:xt store ; 11:10:21 why is it called hashforth? 11:10:33 WilhelmVonWeiner, because it's named after #forth 11:10:41 # = hash 11:11:04 --- quit: ashirase (Ping timeout: 246 seconds) 11:11:11 oh 11:11:13 poundforth 11:11:18 kekeke 11:11:19 my d:create makes a header, with the xt field pointing to here and a class field of class:data 11:13:52 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 11:17:06 (note that these are in my VM assembly rather than in Forth per se) my VARIABLE is merely DEFINE-WORD VARIABLE ( -- ) CREATE 0 LIT , END-WORD , but CREATE is DEFINE-WORD CREATE ( -- ) PARSE-NAME DUP 0 LIT <> +IF ALLOCATE-STRING HERE NEW-CREATE DUP 3 LIT ROLL 3 LIT ROLL ROT NAME>WORD DUP LATESTXT-VALUE ! GET-CURRENT WORDLIST>FIRST OVER NEXT>WORD GET-CURRENT FIRST>WORDLIST +ELSE 2DROP &X-NO-PARSE-FOUND ?RAISE +THEN END-WORD 11:19:31 the equivalent in Forth would be : VARIABLE CREATE 0 , ; and : CREATE PARSE-NAME DUP 0 <> IF ALLOCATE-STRING HERE NEW-CREATE DUP 3 ROLL 3 ROLL ROT NAME>WORD DUP LATESTXT-VALUE ! GET-CURRENT WORDLIST>FIRST OVER NEXT>WORD GET-CURRENT FIRST>WORDLIST ELSE 2DROP ['] X-NO-PARSE-FOUND ?RAISE THEN ; 11:20:28 too many caps :) 11:20:37 :D 11:22:58 crc: I CANT HEAR YOU! 11:23:02 :d:create (s-) 11:23:03 (s-) &class:data #0 d:add-header 11:23:03 here d:last d:xt store ; 11:23:23 such brevity wow 11:24:19 Retro is awesome 11:24:54 my CREATE lacks brevity because the word creation primitive it use, NEW-CREATE, does barely anything at all, only creating an entry in the word table, and thus all the other crap is necessary for allocating a name for the word, setting up wordlists, and like 11:25:29 I don't have wordlists as part of my core language 11:26:00 my VM knows nothing about wordlists, but wordlists exist in the language as bootstrapped in VM assembly 11:29:05 I only had vocabularies / wordlists in retro11, I droppe them in 12 as I didn't find them to be neccessary for the things I do. 11:30:12 The namespace prefixes I use are enough for me and avoid some complexity and state. 11:30:37 hashforth is a more traditional forth, so it doesn't have those prefixes 11:32:44 The namespace prefixes are just a naming convention; I use them in both retro and my (incomplete) port of some of my vocabularies to ANS. 11:34:25 e.g., all string words start with s:, floating point words with f:, etc 11:38:47 I currently have three wordlists - the core forth-wordlist, the multitasking task-wordlist, and the multitasked IO io-wordlist 11:39:48 and I don't use the traditional VOCABULARY, ALSO, etc. words but rather five words: WORDLIST SET-ORDER SET-CURRENT GET-ORDER GET-CURRENT 11:42:02 mind you you can implement the really traditional words in terms of those 11:43:47 (I know I'm supposed to be writing a more traditional Forth with hashforth, but I understand the words I am using better than the traditional ones) 11:44:41 also 11:44:42 finally 11:44:47 multitasking really works! 11:47:21 tabemann: are you using the PAUSE approach or the equiv of timer interrupts? 11:47:46 attoforth used a per-word countdown; hashforth uses PAUSE 11:48:24 getting IO to work with hashforth was surprisingly complex 11:48:36 multitasked IO that is 11:51:01 note that IO was also complex in attoforth, but the difference was that the details of multitasked IO was mostly implemented in C in attoforth but are mostly implemented in Forth in hashforth 11:52:05 I had written a big complex IO manager in C in attoforth which had the effect of greatly simplifying multitasked IO on the Forth side in it 11:52:46 whereas hashforth just has thin layers over poll(), read(), and write() and the rest is all in Forth 11:52:53 iirc, PAUSE switches to the next task, yes? So many IO primitives you have there have some ya-ready? check, no? 11:54:47 attoforth does have a lot of primitives whereas hashforth has very few 11:55:15 aah, yes you have poll(2) I see 11:57:04 are you looking at the hashforth sources right now? 11:58:08 no, just the poll manual page 11:58:15 where do I find these sources btw? 11:59:14 https://github.com/tabemann/hashforth 11:59:34 currently you need attoforth to build the images, but I hope to get it self-hosting at some point in the near future 12:00:26 in many ways, it's attoforth 2.0, simpler, leaner, less complex, less unnecessary crap 12:03:07 currently it's TTC, whereas attoforth was ITC, but I'd like to at some point in time throwing a JIT onto that 12:03:16 *throw 12:03:23 make it a jvm? 12:03:38 translate the ttc to stc? 12:03:51 not a JVM, but make it so that it automatically translates TTC code into STC/NCI code 12:04:16 what is nci? 12:04:23 native code inlining 12:04:54 ah 12:04:56 currently though it's designed for portability 12:07:55 after all, it's a proof-of-concept for #forth 12:11:10 I should at some point at support for double cells, but haven't felt the need as of yet 12:11:16 *add 12:13:09 --- join: rain1 (~My_user_n@unaffiliated/rain1) joined #forth 12:13:48 hey 12:18:33 what concept are you proving? 12:18:52 hi 12:31:55 back 12:32:21 it's just basically intendned to be an example of what #forth should look like 12:47:35 ah, you mean hashforth, not #forth, the channel 12:52:40 #forth is a possible informal new standard we are coming up with, supposedly 12:52:50 hashforth is named after #forth 12:53:28 corecode: there's an informal effort in the channel to create a common set of ISAs for forth systems 12:54:27 like, cpu design? 12:54:30 assuming this is successful, it'll provide an option to achieve some degree of portability 12:55:05 making CPU archs based on it is a discussed possibility 12:55:11 corecode: yes 12:55:39 binary compatibility or code compatibility? 12:56:32 we're aiming at at least code compatibility assuming matching cell size/token type and endianness 12:56:41 ok 12:56:58 possibly binary compatibility as well 13:03:30 i don't think i understand what this is for 13:07:28 if you haven't noticed, we aren't exactly fans of ANS around here, yet some of us have recognized the need for some standard nonetheless 13:07:42 aha 13:08:19 so we can make code that we can run on different implementations of ours rather than having code be fixed to a single implementation 13:08:41 yea i see the source-level appeal 13:13:39 I should get hashforth to be self-hosting 13:14:01 i.e. hashforth should be able to create its own images, rather than relying on attoforth 13:15:30 anyways, time to take a shower, bbl 13:24:04 --- quit: xek (Ping timeout: 246 seconds) 14:00:18 --- quit: tabemann (Ping timeout: 240 seconds) 14:13:46 --- join: tabemann (~tabemann@24.196.100.126) joined #forth 14:26:59 --- join: X-Scale (~ARM@43.80.108.93.rev.vodafone.pt) joined #forth 15:11:40 --- quit: tabemann (Ping timeout: 250 seconds) 15:22:41 --- join: tabemann (~tabemann@2600:1700:7990:24e0:8d7a:3d82:9669:8573) joined #forth 15:50:40 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 15:51:08 hi 16:48:32 hey guys 16:52:05 hi tabemann 17:27:07 has siraben been around? 17:27:17 just saw the article on hackaday about his forth 17:28:07 MrMobius: I'm here 17:28:13 Ah I just saw it too 17:28:46 url? 17:29:31 https://hackaday.com/2019/01/25/pocket-forth-invades-your-ti-calculator/ 17:29:55 cool! 17:30:09 I haven't committed in a while, time to do that soon 17:30:11 Thanks 17:39:24 yep. good job 17:45:07 --- join: smokeink (~smokeink@42-200-117-45.static.imsbiz.com) joined #forth 17:45:51 --- quit: smokeink (Client Quit) 17:48:20 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 17:51:24 cool indeed! 17:51:43 (hey siraben, MrMobius, rdrop-exit) 17:56:20 Hello tabemann 17:56:55 I got hashforth to the point that it no longer crashes when I try to do things like sleeping while multitasking 17:57:31 Cool 17:58:37 I am also including my buffer code from attoforth in with hashforth, to make simpler executing whole files worth of code without having to execute them line-by-line 17:59:21 (all that mainly entailed was stripping out all the "smart" code functionality, because that felt like premature optimization anyways) 18:00:17 (that and adding support for ALLOCATE/RESIZE/FREE, because what I wanted to do with it would have been difficult if I allocated data in the user space) 18:00:55 --- join: smokeink (~smokeink@42-200-117-45.static.imsbiz.com) joined #forth 18:01:01 hey smokeink 18:03:11 hey 18:03:13 what's up 18:04:13 just working on hashforth 18:04:17 you? 18:04:40 Those things seem optional, are you done with the VM already? 18:04:48 the VM itself is done 18:05:06 I'm more working on the overall ecosystem 18:05:46 (the only exceptions is I might add more services and double cells to the VM) 18:06:15 (I haven't had a need for double cells, but on 16-bit and 32-bit systems they may be desired) 18:07:57 * smokeink doing some cleaning work at home 18:08:26 Since the goal of the VM is portability, perhaps there should be a few different ports to different platforms. 18:09:10 the VM as written will work on 16-bit, 32-bit, and 64-bit archs with little more than recompilation 18:09:32 one goal I have at the moment is to get hashforth to be self-hosting 18:09:45 so it will no longer need attoforth to be built 18:10:06 Have you tested your assumption? 18:10:15 tabemann: i tried to completely avoid double cells by coding all the multiply and divide words to use */mod 18:10:40 Will it work despite different alignment requirements and endianess. 18:11:04 at the present it only supports the endianness of the system it was built on 18:11:20 and it assumes that the system doesn't require alignment 18:12:04 it will require modification for systems that require alignment 18:12:49 particularly because the cell size is different from the (small) token size on most systems 18:14:07 Cell size is ok, since per the earlier discussion there would be a different VM for each of the 3 major cell sizes. 18:15:01 an unlikely portability thing would be if char size <> 1 18:15:47 I'm not assuming char size, because it is very likely that the actual char size will be variable 18:15:54 dave0: impossible. you mean CHAR_BITS 18:16:18 rather I've coded it with the assumption that the user will be handling encodings and like on their own 18:16:29 and that all "char" operations actually act on bytes 18:17:00 PoppaVic: nah i mean like instead of 1+ you use char+ 18:17:43 1+ versus CHAR+ is pointless, because modern encodings are variable-size 18:17:58 UTF-8 and UTF-16 18:18:01 well, a CHAR is always the smallest unit, so 1+ works 18:18:04 I thought the point of the VM you were building was to be a virtual chip. 18:19:12 Similar to the JVM. 18:19:52 Except instead of one, there would be four variants, 16-bit, 32-bit Small, 32-bit Large, and 65-bit. 18:20:00 yes 18:20:25 65! 18:20:40 I was wondering about 65-bit computing there 18:20:53 Portability of the image loaded onto one of those machines would be guaranteed. 18:21:02 Sorry 64-bit, typo :) 18:21:31 sometimes 64 bits just isnt enough 18:21:32 But only across the same Bit-Width variant. 18:22:50 to me endian-independence requires writing endian-independent code at the source code level, and the images themselves as written are not endian-independent, even though that could be changed 18:23:22 i caved and added UM* and UM/MOD which use doubles cos otherwise you can't code bignums 18:23:45 The source code wouldn't care what the endianess of the underlying platform, only of the VM standard. 18:24:25 The VM image always has the same endianess. 18:25:06 I love explaining - over & over - the same basics. 18:25:54 If I have an image file targeting your VM, it should run unchanged on any implementation of the VM. 18:26:17 Som optionals might throw traps, but that's ok. 18:27:47 That's the main difference between a VM approach to portability and a language standard approach. 18:27:47 at the present the image file targets either a big-endian or a little-endian VM, mainly because getting true endian-independence was not a high prioriority for me, particularly because it'd be hard to achieve since the image contains code which cannot be guaranteed to be endian-independent in and of itself 18:28:07 *priority 18:28:37 --- join: pierpal (~pierpal@host53-189-dynamic.17-79-r.retail.telecomitalia.it) joined #forth 18:28:45 --- quit: pierpal (Remote host closed the connection) 18:28:56 there's fundamentally no way that we can truly enforce endian-independence because we have byte addressing rather than word-addressing 18:28:56 do you have to relocate the image file? 18:29:21 or load it at the same address every time? 18:29:27 dave0: yes I do - but the data portions of the image file are left unmodified 18:29:48 the image files are meant to be able to be loaded into any place in memory 18:30:33 The image is NOT endian independent, they are endian specific, but the endianess is that of your VM standard, not the underlying platform. 18:31:47 the VM could be made to ensure a particular endianness, yes, albeit at a performance cost 18:32:08 so yes, one could make a VM that ensures an endianness different from that of the underlying platform 18:32:13 There's always a performance cost to portability. 18:32:43 I would recommend you standardize on little endian, and make big endian platforms pay the extra penalty. 18:32:56 that's what I was thinking too 18:33:09 --- quit: proteusguy (Remote host closed the connection) 18:33:24 Then there's also alignment independence to take care of. 18:33:47 These were the two things I asked you about when you first started this project. 18:34:38 i grew up on m68k which is big endian so i thought that was best... but now i've used x86 for years and i think little endian is better heh 18:34:40 Personally, I think the "binary file compatability" is also a rabbit-hole. Since all files have that issue. 18:35:11 Portability is always a rabbit hole. 18:35:21 LE just won the war, BE always made more sense 18:35:44 yeah BE is how you write numbers in mathematics 18:35:55 You say to-ma-to, I say tomato. 18:36:08 rdrop-exit: no. Yer speaking of opcodes and CELLS that are portable, then you throw in files - and I won't even imagine how fucked-up OSX is about these files 18:36:21 rdrop-exit, I could always change hashforth so it ensures alignment by default; the problem is that when tokens are 8/16 bit but cells are 32 bit, and 8/16 bit tokens are intermixed with 32 bit cells, ensuring alignment is a fucking pain 18:36:46 Yes it's absolutely a pain. 18:36:50 rdrop-exit: THe internet decided. alas, everyone works harder. 18:37:31 Portability is hard. 18:38:10 m68k also was very picky about alignment, anything bigger than a byte had to be on an even address 18:38:12 No, floors are hard.. Cinderblock is hard - don't headbang. 18:38:39 back 18:38:47 dave0: that's true most places - unless you are willing to suffer huge penalties and the loss of yer firstborn child. 18:39:17 Reminds me of the Airbourne song, "There's no way but the hard way, get used to it" 18:40:19 back in an hour 18:40:20 know what, both x86/x86-64 and newer ARM don't require alignment for most memory accesses (except for LDM/STM and LDRD/STRD on ARM), so I might as well not force alignment on the VM implementation, and require implementers of versions on platforms that do require alignment to code around it rather than forcing alignment unnecessarily on the x86/x86-64 and ARM-using masses 18:41:03 Although if your VM gets implemented in HW or FPGA the overhead goes away. 18:42:49 Even if the x86 doesn't require alignment, non-aligned accesses are still much more expensive. 18:43:12 --- quit: dave0 (Quit: dave's not here) 18:43:42 more expensive than doing a check for alignment and correcting the address in question if it's unaligned? 18:44:05 I mean, that's at least an AND, a branch, and a bit of math right there 18:44:06 ? 18:44:49 what I mean is let's say we have an 8 bit token followed by a 32 bit cell 18:45:04 it's very likely that the 32 bit cell will be unaligned 18:45:29 so either we do a test and a computation to calculate an aligned address for the 32 bit cell 18:45:32 It all depends on what your VM standard imposes 18:45:46 or we read the 32 bit cell as individual bytes and bitshift and OR them together 18:46:22 The point is the images are targeted to whatever you decide are your VM's requirements. 18:46:54 what I'm proposing is that the standard doesn't care about alignment, and if individual implementations care about it, it is up to them to see fit to manually read unaligned cells as separate bytes 18:49:12 so we've basically determined here that the VM standard will be little-endian and alignment agnostic 18:49:39 That's fine, my point is those two things, endianess and alignment, need to be pinned down. 18:50:55 yes 18:51:30 Cool 18:53:36 So you're initial implementation of the VM on your chosen initial platform, will need code to deal with these. 18:54:11 * your 18:57:10 well, as it's on x86-64, those are already dealt with (while unaligned access is slow, I suspect that manually coding around unaligned access will be even slower) 18:58:43 If your coding in C, you'll be running into undefined behavior if you cast a byte pointer into something else even if the x86-64 doesn't mind. 18:58:48 * you're 19:00:55 damn nasal demons 19:01:21 I agree 19:02:03 The compiler writers have killed C's simplicity. 19:02:34 C is just a tool to generate asm. Fuck it. Check the output and go. 19:02:44 I'm used to treating C as if it were essentially portable assembly, but things have changed since C99 and like 19:03:29 Same here, PoppaVic's attitude is the only way to go I think 19:03:41 "undefined" means "the standard isn't going to get involved" - so, use gcc and abuse it. 19:04:38 The HOLY STANDARD is for folks writing corporate code for corporate drones and porpoises. "Standards are a fine guideline." 19:04:40 in theory in undefined behavior the compiler can make demons fly out of your nose 19:05:11 Cheeky bastards, how dare they access my nose. 19:05:43 Elizabeth: You're pirates. Hang the code, and hang the rules. They're more like guidelines anyway. 19:07:10 --- join: proteusguy (~proteusgu@110.164.217.65) joined #forth 19:07:10 --- mode: ChanServ set +v proteusguy 19:07:16 hey 19:07:36 The nice thing you will accomplish with you're VM is that there will be no undefined behavior, true portability. 19:07:49 * your 19:08:18 Why do I keep switching my "your" and "you're", argh. 19:08:47 "undefined" just means "implementation dependent" - so, you MAY do that for shit you don't nail down: like SYS calls beyond what you define - if someone gets clever, and you plan to implement more code later, HIS CODE is broken 19:09:08 rdrop-exit: try "yer" I do enjoy irking purists ;-) 19:09:18 :) 19:10:11 You're SYS calls have a defined behavior, if the service is implemented perform it, if not trigger a "Unimplemented Service" trap. 19:10:29 That's much better than pulling demons out of your ass. 19:11:05 I did it again. 19:11:08 rdrop-exit: traps are for pansies: do what you document; reserve what you don't - if someone plays dipshit, they get burned. Caveat Emptor. 19:11:22 no, that YOUR was correct 19:11:47 I meant the precedding sentence. 19:11:51 YOUR is possessive; you're is a CONTRACTION; 'yer' is what either sounds like anyway ;-) 19:11:57 ahh 19:12:29 I don't worry much about traps. People tend to build their own, anyway 19:12:54 otoh, I have always favored claymore mines and similar boobytraps. 19:13:46 The point of the SYS call was to give the VM a defined mechanism for optional extensions. 19:13:57