2024-04-14 00:40:32 <crc         > zelgomer: in that case, for a standard sysgem, I'd expect an xt on the stack after the ;. In between the [ and ] there could be an implementation specific number of values.
2024-04-14 00:41:12 <crc         > (similarly with [ ] in a standard colon definition)
2024-04-14 00:51:05 <crc         > Looking at the ANS standard, it would appear that :noname should put the xt on the stack, followed by whatever control data is needed (if using a single stack for both purposes). The ; would clean up the control structures. So the xt may not be easily accessible until after the ;.
2024-04-14 01:30:43 <zelgomer    > thanks
2024-04-14 01:32:29 <zelgomer    > so for any colon definition, you would consider the state of the stack to be implementation define? e.g., even   69 : foo  literal ;  would result in undefined behavior in your opinion?
2024-04-14 01:38:10 <zelgomer    > state at the beginning of the definition, i mean
2024-04-14 01:56:57 <crc         > yes, that might move part of the control data into the definition
2024-04-14 01:57:25 <crc         > : foo [ 69 ] literal ;  would work though
2024-04-14 02:01:24 <zelgomer    > i think i can really simplify how i've been doing this, then
2024-04-14 02:01:44 <zelgomer    > thanks
2024-04-14 14:46:34 <vms14       > there's more to the Forth philosophy than: simplify, don't make stuff you don't need and factor your code?
2024-04-14 14:47:36 <vms14       > i can see the benefits of simplifying stuff, it works great
2024-04-14 14:57:44 <vms14       > and not making stuff you don't need is to simplify
2024-04-14 14:58:12 <vms14       > also factoring your is striving to find the simplest solution
2024-04-14 14:58:37 <vms14       > your code*
2024-04-14 16:25:16 <lf94        > I love forth so much
2024-04-14 16:25:34 <lf94        > each passing day it's like opening my third eye to programming
2024-04-14 16:30:27 <vms14       > :0
2024-04-14 17:23:22 <lf94        > are there any amd64 forths that expose SIMD
2024-04-14 17:23:59 <lf94        > > xt < what does this stand for?
2024-04-14 18:04:38 <GeDaMo      > eXecution Token
2024-04-14 18:10:07 <lf94        > thanks :
2024-04-14 18:10:09 <lf94        > :)
2024-04-14 18:11:14 <GeDaMo      > I don't know of any SIMD forths
2024-04-14 18:11:33 <GeDaMo      > I keep threatening to write something with whole array operations
2024-04-14 18:11:56 <thrig       > May Forth is coming up...
2024-04-14 18:37:24 <KipIngram   > GeDaMo: I definitely want to build something that does array operations.  Sort of a fusion of Forth and APL.
2024-04-14 18:38:17 <GeDaMo      > I saw something like that
2024-04-14 18:38:33 <KipIngram   > And I'm toying with the idea of supporting general geometric algebra quantities - those can have parts of all kinds - scalar part, vector part, bivector (2D array) part, etc. - up to whatever dimension you're working in.
2024-04-14 18:38:47 <KipIngram   > Yeah, we talked about it here a while back.
2024-04-14 18:38:54 <GeDaMo      > https://github.com/chmykh/apl-life ?
2024-04-14 18:39:19 <KipIngram   > Name starts with a u, I think.  uiwa or something like that?
2024-04-14 18:39:41 <KipIngram   > Uiua.
2024-04-14 18:39:47 <lf94        > I was just wondering if anyone has tried exposing SIMD instructions nicely in forth. It could be nice for some heavier compute stuff.
2024-04-14 18:40:02 <KipIngram   > https://www.uiua.org/
2024-04-14 18:40:13 <lf94        > For fun I should try exposing intel hardware sha functions to gforth
2024-04-14 18:40:18 <lf94        > As an exercise
2024-04-14 18:40:37 <KipIngram   > Yeah, it would.  I haven't, but anything trying to do array work should expose that, or GPU machinery, or SOMETHING.
2024-04-14 18:41:57 <GeDaMo      > I was a little obsessed thinking about loop tiling in relation to array operations in an interpreted language
2024-04-14 18:42:35 <GeDaMo      > In order to take advantage of CPU cache for performance reasons
2024-04-14 18:43:46 <KipIngram   > I haven't delved far enough into it to talk sensibly about any of the details yet.  Mostly just vague ideas I'm pondering.
2024-04-14 18:45:05 <KipIngram   > And this would all be part of some extended layer "type supporing" facility; the native base system wouldn't do any of this.
2024-04-14 18:46:19 <KipIngram   > Somewhere in my pdf files I've got a document describing the HP-48 architecture and language - it has some good bits in it for keeping up with what various quantities are.
2024-04-14 18:58:28 <DKordic     > lf94: I heard WinForth has SIMD.
2024-04-14 18:59:15 <lf94        > Nice
2024-04-14 19:05:30 <DKordic     > Do We need ""noname:"" when We can "": noname ... ;""?
2024-04-14 19:05:30 <DKordic     > IMHO ""XT"" is an obstruction, which is... marketed as ""abstraction""!!  Machine Code Address is reasonable.
2024-04-14 19:05:31 <DKordic     > Re: ""undefined behaviour"": Isn't that a confused concept?
2024-04-14 19:08:39 <lf94        > bad name, yea
2024-04-14 19:08:52 <lf94        > "behavior dependent on the implementation"
2024-04-14 19:10:39 <zelgomer    > wtf are you going on about?
2024-04-14 19:10:59 <zelgomer    > is there something about forth that it only attracts the mentally ill?
2024-04-14 19:11:40 <DKordic     > :)
2024-04-14 19:11:40 <lf94        > maybe
2024-04-14 19:13:36 <zelgomer    > i'll do my best to respond.
2024-04-14 19:14:19 <DKordic     > Copy the address of Machine Code, stored in ""Here"".  Compose the Machine Code.  Execute it.  Like LaForth?!
2024-04-14 19:14:27 <zelgomer    > 1. yes, :noname is needed. ": noname ... ;" is not the same thing, and if you write it to produce the same thing, then you have decided that nobody can ever create a word called "noname"
2024-04-14 19:15:18 <zelgomer    > 2. "xt" is just a commonly used term to refer to "a value that you can execute." terms like these are necessary because they are represented differently in different systems, and i must have some way of communicating with you motherfuckers
2024-04-14 19:15:39 <zelgomer    > 3. no, "here" is not necessarily the same thing as an xt.
2024-04-14 19:16:17 <zelgomer    > i have no response to that rest of that inane rambling
2024-04-14 19:16:54 <lf94        > Thanks for clarifying xt for me
2024-04-14 19:16:56 <lf94        > :p
2024-04-14 19:19:26 <DKordic     > Sorry, http://christophe.lavarenne.free.fr/ff/ffcodegen.html
2024-04-14 19:25:18 <DKordic     > That Generalization increases the Inherent Cmoplexity.  AFAICS We need to clarify the question to proceed.  _Abstract_ Algebraic Data Type would be an excellent choice, IMHO.
2024-04-14 19:29:59 <zelgomer    > again, what the fuck are you talking about? DKordic, what is left on the top of the stack after ' dup ?
2024-04-14 19:33:12 <DKordic     > intro.txt
2024-04-14 19:33:18 <DKordic     > >> [ dfn ( ( add I.1 I.2 ) +1 1 )  ( I.1 +1 ( I.2 +1 1 ) ) ]  ( is ( iteration ( + n.1 n.2 ) ) ( add ( iteration n.1 ) ( iteration n.2 ) ) )
2024-04-14 19:33:18 <DKordic     > [ dfn ( nop : ; )  ( : ; ) ]  [ dfn ( Forth! F.1 F.2 : ; )  ( F.2 ( F.1 : ) ; ) ]
2024-04-14 19:33:19 <DKordic     > ( is nop ( Forth! dup drop ) ) <<
2024-04-14 19:34:24 <zelgomer    > please seek professional help
2024-04-14 19:36:57 <DKordic     > Vote for me for the Charles Moore Award.
2024-04-14 20:11:38 <lf94        > very lisp-y
2024-04-14 20:12:31 <thrig       > less is Moore
2024-04-14 20:12:51 <lf94        > that'd be good on a t-shirt
2024-04-14 20:14:25 <thrig       > maybe YAGNI on the other side
2024-04-14 20:18:11 <DKordic     > lf94: W/Continuation-passing_style
2024-04-14 20:20:54 <DKordic     > Here "";"" can be omitted, the so called ""eta-equivalence"".  ""0K"" is a better name than "":"".  I made a mistake: it should be (F.2 0K).
2024-04-14 20:21:41 <lf94        > thrig: hahaha
2024-04-14 20:21:46 <lf94        > people will think we're being all hip
2024-04-14 20:22:15 <lf94        > why 0K intead of OK
2024-04-14 20:23:06 <DKordic     > 0 Ki B implementation of Forth ;)
2024-04-14 20:24:43 <thrig       > maybe to help tell apart 0K ranch cattle from OK ranch cattle
2024-04-14 20:24:43 <lf94        > impossible
2024-04-14 20:24:49 <lf94        > thrig: lmfao.
2024-04-14 20:25:10 <thrig       > these are often confused if your font is bad
2024-04-14 20:26:16 <lf94        > http://0x0.st/X-wv.png thrig
2024-04-14 20:27:43 <lf94        > thrig ignore that one
2024-04-14 20:27:45 <lf94        > http://0x0.st/X-ww.png
2024-04-14 20:27:48 <lf94        > this one's got a stack
2024-04-14 20:28:27 <thrig       > or a weird tophat with some butter or lard on it?
2024-04-14 20:29:15 <lf94        > why a tophat
2024-04-14 22:07:38 <crc         > zelgomer: a minor thing, using a ": noname ... ;" doesn't prevent future words from using the same name.
2024-04-14 22:13:47 <crc         > DKordic: A.6.2.0455 in the ANS standard document discusses why :NONAME exists. In short, it gives access to the Forth compiler to the user, separating it from the act of creating a header.
2024-04-14 22:19:51 <zelgomer    > if you implement your : so that it treats the name "noname" special, then you prevent that name from ever being used by any colon definition
2024-04-14 22:24:00 <crc         > or just implement : using :noname
2024-04-14 22:24:17 <zelgomer    > what?
2024-04-14 22:28:54 <crc         > something like ": : make-header :noname ;"
2024-04-14 22:30:18 <zelgomer    > that makes : behave like :noname
2024-04-14 22:31:18 <zelgomer    > DKordic proposed writing : so that when the name that follows : is the word "noname" then it works like :noname. i'm saying that if you do that, then you can never create a word with : and call it "noname", which in my opinion is ugly
2024-04-14 22:32:38 <crc         > gforth does something similar; in the copy I have, it defines : as ": : header (:noname) ;" (and :noname also makes use of the "(:noname)" word).
2024-04-14 22:32:54 <crc         > that would be ugly, and not something I'd be comfortable with
2024-04-14 22:33:00 <zelgomer    > but this is not what's being discussed
2024-04-14 22:54:53 <DKordic     > Sorry, I was not clear enough.  I meant a mere convention like "": _  ... ; ' _"".  ""Here:"" is shorter and more clear to me than ""noname:"".  Even better: ""Here is: ... ;""?
2024-04-14 22:59:51 <crc         > I used to use :: instead of :noname
2024-04-14 23:01:49 <zelgomer    > DKordic: are you just talking about calling it something different?
2024-04-14 23:02:00 <zelgomer    > i don't call it :noname in mine. who cares what you call it?
2024-04-14 23:02:28 <zelgomer    > but maybe it's unclear to you because it's not "noname:", it's ":noname"
2024-04-14 23:02:35 <zelgomer    > as in ":" followed by no name
2024-04-14 23:05:10 <thrig       > "noname" was used by Ulysses to get away from the cyclops
2024-04-14 23:05:53 <DKordic     > :)
2024-04-14 23:22:42 <nature      > Good evening! I want to implement a dictionnary but not in the main memory of my vm. I think of the dictionnary kind of like a jump table with labels and addresses. The addresses point to the main memory where the actual bytecode and data is located.
2024-04-14 23:24:07 <nature      > Now, should the dictionnary be implemented directly as part of the vm, so it can be edited/searched with opcodes or should I just provide a second block memory through my vm?
2024-04-14 23:26:17 <nature      > I was thinking of the latter, but then I don't know what size I should allocate and how I should distribute the binary images of my vm, right now I like that my assembler produces a single .rom file that can be loaded by my vm, and it would suck to have two separate images for the two blocks of memory
2024-04-14 23:29:40 <nature      > The reason why I need my dictionnary to be separate from the actual code is that I want definitions to be able to "fall through" a la colorforth, a silly example:
2024-04-14 23:30:12 <DKordic     > nature: Welcome.  I would start with an Association List, as is the tradition.  Yes, it might not be needed, so I would keep it in a separate Data Structure and included as needed.
2024-04-14 23:30:36 <nature      > :add2 ( x -- x ) 1+ :add1 1+ ;
2024-04-14 23:31:18 <nature      > DKordic: Do you mean a linked list?
2024-04-14 23:31:47 <DKordic     > I call that (Instruction) Pipeline Continuation.
2024-04-14 23:31:56 <zelgomer    > you may want a -; there before :add1, but anyway i get the idea. nature, for inspiration you may want to look at camelforth by brad rodriguez. he's ported it to a few harvard model platforms and uses separate header, code, and data spaces
2024-04-14 23:33:25 <DKordic     > Yes, for a start.
2024-04-14 23:34:00 <nature      > Got it, my vm is more like a von neumann type of vm
2024-04-14 23:34:45 <nature      > I heard Harvard architecture doesn't work so well with forth (from waforth)
2024-04-14 23:35:02 <zelgomer    > yeah
2024-04-14 23:35:40 <zelgomer    > anyway, you could have words to select which memory space you're working with, similar to the "section .text" type stuff assemblers tend to use
2024-04-14 23:36:55 <nature      > So basically kind of like with memory banks?
2024-04-14 23:37:18 <zelgomer    > banks, sections, segments, regions, whatever you want to call them
2024-04-14 23:37:20 <DKordic     > Because it has separate Instruction and Data Caches which have the _advantage_ of working in parallel!  It needs to be taken into consideration.
2024-04-14 23:39:18 <nature      > Any good way to "dump" an image containing two or more memory banks?
2024-04-14 23:39:41 <zelgomer    > you have some kind of header that says how big each is
2024-04-14 23:39:51 <zelgomer    > and/or where they start in the image
2024-04-14 23:40:28 <DKordic     > I don't think You are concerned with ""Banks"", but Cache Lines and VM Pages.
2024-04-14 23:40:58 <zelgomer    > nature: what you're talking about is basically how most OS binaries work. DOS MZ, Windows executables, ELF, etc.
2024-04-14 23:41:07 <DKordic     > mmap syscall.
2024-04-14 23:42:19 <nature      > ooooh, can this make sense for a forth system? I want to find a good balance between perf and simplicity
2024-04-14 23:42:39 <nature      > DKordic: What do you mean by cache lines?
2024-04-14 23:43:08 <zelgomer    > pretty sure at this point that DKordic is a markov chain or ai
2024-04-14 23:43:37 <DKordic     > :)
2024-04-14 23:44:17 <thrig       > maybe the model long since collapsed
2024-04-14 23:44:42 <nature      > ^^
2024-04-14 23:46:27 <DKordic     > nature: Unit of Data on which Cache (Memory) operates on.  Likely 64 Bytes.
2024-04-14 23:49:37 <DKordic     > nature: I recomend not to waste time (effort) on WebAssembly.
2024-04-14 23:50:05 <nature      > DKordic: I will not! :) I am building my own vm!
2024-04-14 23:50:14 <crc         > The space needed for dictionary headers can vary a lot, depending on what all you track for them. E.g., in RetroForth, the headers consume about 41kb for the 652 words. In Konilo, I use a little under 7kb for 597 words.
2024-04-14 23:50:42 <MrMobius    > DKordic: why not webassembly? I was thinking about doing that myself
2024-04-14 23:51:17 <thrig       > firefox requires a lot of security updates; not a very good OS in that regard
2024-04-14 23:51:46 <nature      > crc, my header for now would probably just contain the label (counted string) and the address in the main memory of the code for the word
2024-04-14 23:53:14 <nature      > maybe a pointer to the previous entry, but I feel that if I figure out how to grow the dictionnary from high memory to low, with a pointer to LATEST, I could do without link and save a cell per definition
2024-04-14 23:53:36 <crc         > keeps it simple. Konilo's headers have a link to the previous entry, the address, and a hash of the name.
2024-04-14 23:54:48 <nature      > The hash of the name!? :o
2024-04-14 23:54:55 <crc         > yes
2024-04-14 23:55:01 <nature      > haven't thought of that, that's smart
2024-04-14 23:55:17 <nature      > predictable size for the entries then
2024-04-14 23:55:32 <crc         > it has some drawbacks: no ability to implement WORDS or SEE
2024-04-14 23:56:15 <nature      > Why not SEE?
2024-04-14 23:56:30 <nature      > it could compute the hash and find the entry no?
2024-04-14 23:57:00 <crc         > There's no table of word names saved anywhere
2024-04-14 23:58:35 <nature      > does SEE parses the name? if yes, you can just compute the hash and then from the dictionary find the entry. Am I missing something?
2024-04-14 23:59:33 <crc         > "SEE name", but name is just a pointer to the instructions/bytecode. I can track addresses back to the headers, but that only gets a hash, not the name.