2022-10-25 01:10:38 <KipIngram   > ^
2022-10-25 07:55:32 <dinklebink  > hi
2022-10-25 07:57:31 <olle        > \o
2022-10-25 07:57:47 <dinklebink  > I'm trying to understand programming
2022-10-25 07:57:53 <dinklebink  > I should probably just take a 101 course
2022-10-25 07:58:06 <dinklebink  > but from what I understand, Forth is a bytecode VM right?
2022-10-25 07:58:10 <dinklebink  > or can be?
2022-10-25 07:58:44 <eris[m]     > no
2022-10-25 07:58:54 <dinklebink  > okay so I'm dumb :)
2022-10-25 07:59:07 <dinklebink  > but when you compile in Forth, what do you compile to?
2022-10-25 07:59:15 <dinklebink  > machine code for the host device?
2022-10-25 07:59:20 <eris[m]     > kind of
2022-10-25 07:59:29 <dinklebink  > and when you use the Forth assembler
2022-10-25 07:59:31 <eris[m]     > forth generally gets compiled to 'dictionary code'
2022-10-25 07:59:35 <dinklebink  > that's ASM for the virtual machine right?
2022-10-25 07:59:40 <dinklebink  > it's not the host machine's ASM
2022-10-25 07:59:42 <eris[m]     > sets of references to dictionary definitions
2022-10-25 07:59:42 <eris[m]     > no
2022-10-25 07:59:48 <eris[m]     > generally it is the host machine's assembly
2022-10-25 07:59:58 <eris[m]     > certain forths run on virtual machines
2022-10-25 08:00:03 <dinklebink  > such as?
2022-10-25 08:00:09 <eris[m]     > retroforth
2022-10-25 08:00:23 <eris[m]     > but traditional forth runs natively using a technique known as 'indirect threading' (unrelated to parallelism)
2022-10-25 08:02:30 <dinklebink  > I thought Forth ran in a VM
2022-10-25 08:02:31 <dinklebink  > tbh
2022-10-25 08:02:44 <dinklebink  > Forth is an interpreter right?
2022-10-25 08:02:50 <dinklebink  > as well as being able to compile
2022-10-25 08:03:15 <eris[m]     > uhm
2022-10-25 08:03:16 <eris[m]     > kind of
2022-10-25 08:03:20 <eris[m]     > define interpreter
2022-10-25 08:03:58 <dinklebink  > like BASIC
2022-10-25 08:04:26 <eris[m]     > thats an example
2022-10-25 08:04:29 <eris[m]     > define your terms
2022-10-25 08:05:09 <dinklebink  > running code line by line
2022-10-25 08:05:11 <dinklebink  > in a sequence
2022-10-25 08:05:16 <eris[m]     > nothing does that nowadays :)
2022-10-25 08:05:25 <dinklebink  > everything uses JIT now right
2022-10-25 08:05:32 <eris[m]     > nope
2022-10-25 08:05:37 <dinklebink  > haha I'm dumbbbbb
2022-10-25 08:05:44 <eris[m]     > even without JIT, 'AST walking' interpreters are slow
2022-10-25 08:05:47 <eris[m]     > like
2022-10-25 08:06:01 <eris[m]     > python translates source code into bytecode
2022-10-25 08:06:04 <eris[m]     > then interprets that
2022-10-25 08:06:10 <dinklebink  > isn't that JIT
2022-10-25 08:06:12 <dinklebink  > am I stupid
2022-10-25 08:06:12 <eris[m]     > nope
2022-10-25 08:06:16 <eris[m]     > thats not a jit
2022-10-25 08:06:19 <dinklebink  > oh well
2022-10-25 08:06:20 <dinklebink  > never mind
2022-10-25 08:06:23 <eris[m]     > a jit compiles bytecode to native code
2022-10-25 08:06:25 <eris[m]     > generally
2022-10-25 08:06:40 <dinklebink  > so forth doesn't use bytecode
2022-10-25 08:06:44 <eris[m]     > it can
2022-10-25 08:06:49 <eris[m]     > 'forth' isn't a single language
2022-10-25 08:07:12 <dinklebink  > right
2022-10-25 08:07:23 <dinklebink  > I'm looking for a bytecode VM that would run on something like an Apple II
2022-10-25 08:07:26 <eris[m]     > but, traditional forth is implemented using the aforementioned dictionary technique
2022-10-25 08:07:31 <eris[m]     > dinklebink: why?
2022-10-25 08:07:38 <dinklebink  > bc this is what interests me
2022-10-25 08:07:42 <dinklebink  > there's UCSD Pascal
2022-10-25 08:08:00 <eris[m]     > you're better off using the 6502 as the virtual machine :P
2022-10-25 08:08:09 <eris[m]     > also, sweet-128
2022-10-25 08:08:21 <dinklebink  > SWEET16 was Woz's thing right
2022-10-25 08:08:21 <eris[m]     > or what was it called
2022-10-25 08:08:23 <eris[m]     > yes
2022-10-25 08:08:25 <eris[m]     > sweet16
2022-10-25 08:08:51 <dinklebink  > Well essentially, I like fantasy consoles, like pico-8, but it would be nice to use something that runs on actual 8-bit hardware
2022-10-25 08:08:52 <eris[m]     > >  SWEET16 runs at about one-tenth the speed of the equivalent native 6502 code.
2022-10-25 08:08:52 <dinklebink  > like CHIP8
2022-10-25 08:09:08 <eris[m]     > chip8 is also a virtual machine :P
2022-10-25 08:09:15 <eris[m]     > there's fantasy consoles based on the 6502
2022-10-25 08:09:24 <dinklebink  > but I don't want an FC based on the 6502
2022-10-25 08:09:30 <dinklebink  > I want one that'll run on a 6502
2022-10-25 08:09:42 <dinklebink  > with reasonable speed
2022-10-25 08:09:51 <eris[m]     > a fantasy console based on the 6502 would run on the 6502
2022-10-25 08:10:03 <eris[m]     > because the 6502 is the CPU
2022-10-25 08:10:10 <eris[m]     > > with reasonable speed
2022-10-25 08:10:15 <eris[m]     > this is your issue
2022-10-25 08:10:25 <dinklebink  > but 6502s differ in implementation and hidden opcodes and stuff
2022-10-25 08:10:39 <dinklebink  > it's not my issue, there are NES games that used bytecode
2022-10-25 08:10:49 <eris[m]     > not for everything
2022-10-25 08:11:00 <dinklebink  > of course I'd have to write an interpreter and write some things in ASM
2022-10-25 08:11:02 <eris[m]     > that's also a space-speed tradeoff
2022-10-25 08:11:04 <dinklebink  > I understand this
2022-10-25 08:11:58 <dinklebink  > https://youtube.lurkmore.com/watch?v=KTOiKtq-rvU someone was poking around with the code for this and realized that all of Koei's old strategy games ran on bytecode
2022-10-25 08:12:17 <dinklebink  > they wrote the games in C and compiled that C to bytecode, then wrote interpreters for every console available
2022-10-25 08:12:38 <eris[m]     > yes
2022-10-25 08:12:51 <dinklebink  > including the game boy, so they were able to write 8-bit games in C, in the late 80s
2022-10-25 08:12:53 <dinklebink  > which is impressive
2022-10-25 08:13:09 <eris[m]     > if you're wondering whether forths are a good fit for this, no - 6502 forths are generally quite slow due to stack use
2022-10-25 08:13:21 <dinklebink  > no I figured from what you said they would be a poor use
2022-10-25 08:13:33 <dinklebink  > but it does give me a goal
2022-10-25 08:14:00 <eris[m]     > (also, compiled forth generally isn't portable across machines)
2022-10-25 08:14:30 <dinklebink  > forth is weird
2022-10-25 08:15:54 <eris[m]     > yes
2022-10-25 08:15:55 <eris[m]     > it is
2022-10-25 08:17:00 <dinklebink  > but forth is still an interpreted language, no?
2022-10-25 08:17:09 <gordonjcp   > not exactly
2022-10-25 08:17:14 <dinklebink  > :(
2022-10-25 08:18:03 <eris[m]     > we established this earlier that it's not
2022-10-25 08:19:11 <dinklebink  > well you said "nothing does that these days" but forth typically doesn't follow modern conventions of anything
2022-10-25 08:19:12 <dinklebink  > so I wasn't clear
2022-10-25 08:21:26 <eris[m]     > forth is kind of an interpreted language and kind of a virtual machine and kind of a compiler and so forth
2022-10-25 08:21:54 <eris[m]     > most forths are distinctly not bytecode virtual machines
2022-10-25 08:22:53 <eris[m]     > a bytecode virtual machine generally has an 'instruction set'
2022-10-25 08:23:38 <eris[m]     > an interpreter consumes some sequence of bytes and matches it against the (closed) instruction set to determine what to execute
2022-10-25 08:24:13 <eris[m]     > you can naively implement bytecode virtual machines using switch statements, lookup tables, and similar techniques
2022-10-25 08:24:40 <eris[m]     > for instance, this is what cpython does
2022-10-25 08:25:24 <eris[m]     > for forth, the implementation 'compiles' source code into lists of memory addresses
2022-10-25 08:26:14 <eris[m]     > this memory address points to another memory address
2022-10-25 08:27:18 <eris[m]     > that 2nd memory address is generally machine code
2022-10-25 08:27:30 <eris[m]     > that determines how to execute what's after it in memory
2022-10-25 08:27:41 <eris[m]     > generally, this is another list of addresses
2022-10-25 08:27:57 <eris[m]     > the first address points to the pointer of machine code
2022-10-25 08:28:19 <eris[m]     > after the pointer to machine code, there's generally a list of addresses
2022-10-25 08:28:26 <eris[m]     > this is called 'indirect threading'
2022-10-25 08:28:39 <eris[m]     > https://www.complang.tuwien.ac.at/forth/threaded-code.html
2022-10-25 08:41:20 <dinklebink  > neat
2022-10-25 08:50:06 <dinklebink  > that explains why forth wasn't so popular in game development at the time then
2022-10-25 08:50:32 <dinklebink  > it wasn't truly portable and if everyone needed more performance than stuff like BASIC offered then why not just move straight down to ASM
2022-10-25 08:53:24 <dinklebink  > or a custom bytecode VM
2022-10-25 09:00:49 <eris[m]     > it can be made truly portable
2022-10-25 09:01:03 <eris[m]     > just the compiled code isnt
2022-10-25 09:01:15 <eris[m]     > compile it on the machine once, distribute that
2022-10-25 10:04:36 <dinklebink  > but I want ppl to have access to the source code so
2022-10-25 10:05:33 <eris[m]     > not all bytecode can be transparently lifted to source code
2022-10-25 18:45:29 <KipIngram   > indirect threading has some advantages in my opinion, but everyone is instinctively sure that it's lower performance.  Interestingly, though, while it often *is* lower performance, it's not ALWAYS.  It really does depend on the target processor.  And it does make certain traditional features of Forth easier to implement cleanly.
2022-10-25 18:46:01 <KipIngram   > It removes the need to have code before each definition list - you just need a cell there.
2022-10-25 18:46:17 <KipIngram   > so you don't have native code all interspersed with your definition lists.
2022-10-25 18:47:30 <KipIngram   > I don't want to make it sound like the performance claim is weak - I'd guess that direct theading will usually win on performance by some small margin.
2022-10-25 18:47:51 <KipIngram   > People also have a tendency to think that code threaded designs "must" be higher performance.
2022-10-25 18:47:56 <KipIngram   > But that's not universally true either.
2022-10-25 18:48:32 <Zarutian_iPad> depends on the architecture of the processor, on canonoical dual stack machine arch from Philip Koopmans book Stack Machines the new Wave, definition lists are first class
2022-10-25 18:48:46 <KipIngram   > Right.
2022-10-25 18:48:51 <KipIngram   > "It depends."
2022-10-25 18:50:14 <Zarutian_iPad> in it the first 32 or 16 addresses can not be ‘called’ as those values are reserved for the primitives implemented directly in hardware
2022-10-25 18:51:17 <KipIngram   > I tend to favor indirect threading because I think it wins the "elegance contest."  And I'm willing to yield a small amount of performance to get that.
2022-10-25 18:52:04 <Zarutian_iPad> in FCPU-16 I decided on 16 directly accessible primitives (one, ext, is used to access the rest)
2022-10-25 18:52:15 <KipIngram   > I figure if I really really really need top performance in some smidge of code, I'll wind up writing something in assembly for the critical section anyway.