2025-01-13 11:32:33 <veltas      > pgimeno: JAForth looks awesome, will have to read/play with later, thanks for sharing
2025-01-13 11:33:18 <pgimeno     > oh just don't get your hopes too high, it's very JA specific, and JA has many quirks
2025-01-13 11:34:04 <veltas      > I know that, don't worry :P
2025-01-13 11:34:25 <pgimeno     > nice, in that case, hope you enjoy it ^.^
2025-01-13 11:34:37 <veltas      > cheers
2025-01-13 11:39:23 <veltas      > Is this your first venture into Forth?
2025-01-13 11:39:51 <pgimeno     > I'd say second, if you count the previous compiler (which did not have interpreting capabilities)
2025-01-13 11:40:15 <veltas      > I'm quite impressed by what you've done here, this looks like it will be really useful to anyone doing stuff for the JupiterAce
2025-01-13 11:40:24 <veltas      > Certainly this is what I'd grab if I wrote anything for it
2025-01-13 11:41:28 <veltas      > Talking of the Python thing anyway
2025-01-13 11:41:47 <veltas      > It is interesting that this can be achieved in the JupiterAce emulator as well
2025-01-13 11:42:23 <pgimeno     > glad you like it! I'd say it's somewhat slow, and I believe it's due to the need to keep compatibility and the separate memory areas. I think I should make everything a single memory area like in a real Z80; it would save a lot of complexity in poke() and peek()
2025-01-13 11:42:44 <pgimeno     > which I believe are a bottleneck here
2025-01-13 11:43:01 <veltas      > What's slow?  The Python one?  How slow are we talking?
2025-01-13 11:43:38 <pgimeno     > the Python one, yes - I've tried it with Mazogs and it takes about 2-3 seconds to compile
2025-01-13 11:43:52 <veltas      > That's fine IMO
2025-01-13 11:44:19 <pgimeno     > yes, it's not fast but there isn't much need for speed given its purpose
2025-01-13 11:45:25 <veltas      > Which do you prefer, the emulator or the Python compiler?
2025-01-13 11:46:54 <pgimeno     > well, each has its pros an cons - the emulator is "perfect", but it makes it harder to extend; on the other hand, Python is widely available out of the box, so you can run it right away in any machine with Python
2025-01-13 11:47:47 <pgimeno     > the emulator is faster, but I am not extending it to add the extra words that the Python version has
2025-01-13 11:48:07 <veltas      > I don't think it's harder to extend is it?
2025-01-13 11:48:23 <veltas      > Can't you write the extra words in the native Forth and 'include' those first?
2025-01-13 11:48:41 <veltas      > I think if the emulator was written in Python it would be slower
2025-01-13 11:50:01 <pgimeno     > oh it's not so easy, if you write the extra words in the user area then they will take user RAM, limiting the RAM available for users; on the other hand the ROM is very compact and it's not possible to extend it in ROM
2025-01-13 11:51:24 <pgimeno     > the new words I added are used for aiding in compilation - a // single line comment (because the Jupiter only supports ( ) comments in compiled code, and they take space), an #INCBIN to include a binary, an #IMPORTSYM to import assembler symbols, and two string enclosing utilities
2025-01-13 11:51:46 <pgimeno     > once the result is compiled, these are no longer useful
2025-01-13 11:52:59 <veltas      > Yeah and generally I think this is something hard to do nicely in Forth, keeping track of what's necessary for building vs running
2025-01-13 11:53:05 <pgimeno     > so, to implement them in the emulator you have to add a ROM trap, parse the words yourself and prepare the RAM the way that Forth would
2025-01-13 11:55:11 <veltas      > How much room is in ROM?
2025-01-13 11:55:17 <pgimeno     > 8 KB
2025-01-13 11:55:21 <veltas      > Could you sneak them in there?
2025-01-13 11:55:33 <veltas      > At end of the ROM part of dictionary
2025-01-13 11:56:55 <pgimeno     > no, it's very crowded, you could optimize a byte here or there but since you can't move addresses, you can't get a contiguous area of a decent size
2025-01-13 11:57:28 <pgimeno     > I may have misunderstood, the ROM size is 8 KB but it's fully used
2025-01-13 11:59:23 <pgimeno     > I've thought about a possible hack, limiting the Jupiter memory to, say, 41 KB instead of 49 KB and use the top of the RAM for extra words that aren't linked and don't appear in a listing
2025-01-13 11:59:39 <pgimeno     > words used only at compilation time
2025-01-13 11:59:43 <veltas      > ROM trap is better
2025-01-13 12:00:11 <pgimeno     > ROM trap is nice, but it doesn't let users write their own compilation aids, which is what I had in mind
2025-01-13 12:00:30 <veltas      > I think you can allow that (?)
2025-01-13 12:01:06 <veltas      > Have a special compilation word that defines a compilation-only word etc
2025-01-13 12:01:35 <pgimeno     > yes, but words need to be in Z80-addressable memory, because every address in a word is a Z80 address
2025-01-13 12:02:31 <pgimeno     > I first thought about having a separate memory for user words, but then I wondered how would I able to interpret them if they are not in the Z80 address space
2025-01-13 12:03:26 <pgimeno     > that's how I came up with the idea of storing them in a higher memory area
2025-01-13 12:04:00 <pgimeno     > JA usually comes with 1K and most users expanded it to up to 17K; 49K is rare
2025-01-13 12:07:26 <veltas      > All this is why the python compiler is better I guess
2025-01-13 12:09:51 <pgimeno     > it's more or less on par, the same problem would exist with the Python one the way it's designed (due to my compatibility requirements), but in this case I *could* place routines in the ROM
2025-01-13 12:11:08 <pgimeno     > there's no ROM after all, besides the main loop and the LINE word definitions
2025-01-13 12:19:52 <pgimeno     > also, well, the Python version makes it easier to add more internal words to the interpreter itself, being a more friendly language
2025-01-13 12:51:21 <veltas      > I think the Python one I would consider either a cross forth, or almost a cross forth
2025-01-13 12:51:42 <veltas      > And I think that's a good model for generating Forth images, ROM's and/or apps
2025-01-13 16:05:04 <veltas      > https://akkartik.name/post/literate-programming
2025-01-13 16:05:43 <veltas      > Ugh I just don't like literate programming at all, programs aren't documentation.  If I want programs to be documentation then being a program comes first, documentation comes second
2025-01-13 16:06:00 <KipIngram   > I agree.
2025-01-13 16:06:25 <veltas      > No offense crc, your literate programming is quite good as far as it goes, just don't want it for myself
2025-01-13 16:06:42 <KipIngram   > After all, mechanical drawings don't explain to you how that part meets its requirements.
2025-01-13 16:07:15 <KipIngram   > Schematics don't tell you about the electronics theory behind the design.
2025-01-13 16:08:20 <veltas      > It's probably best just for writing a program that's the subject of an academic article or blog post, but not for normal programs
2025-01-13 16:08:29 <veltas      > I'd never make it standard
2025-01-13 16:10:29 <crc         > veltas: in recent times, I do a lot less literate coding, mostly now just for things I'm publishing for others to study
2025-01-13 16:16:39 <veltas      > Makes sense
2025-01-13 18:26:17 <xentrac     > KipIngram: I think the idea of literate programs is to be like mechanical drawings and schematics in that they explain the design as clearly as possible so that other people can understand and modify it
2025-01-13 18:27:03 <xentrac     > not that they teach you the theory of algorithms behind the design, unless that's necessary in order for the target audience to understand the design (so it depends on the target audience)
2025-01-13 18:54:06 <KipIngram   > I guess I was just thinking that a drawing might show a bolt here, or a schematic a transistor there - likewise, source code has a for statement here, a function call there.
2025-01-13 18:54:22 <KipIngram   > But the "why" is not addressed.
2025-01-13 18:54:34 <KipIngram   > Why did you need three bolts instead of two?  Etc.
2025-01-13 18:55:57 <xentrac     > Sometimes it is, in the comments on the schematic or print
2025-01-13 18:56:38 <xentrac     > but often it is not
2025-01-13 18:57:34 <pgimeno     > well, the inventor of literate programming himself wrote this in the header of a roman numeral conversion routine: "69. Roman numerals are produced by the print roman int routine. Readers who like puzzles might enjoy trying to figure out how this tricky code works; therefore no explanation will be given." (TeX source documentation p.29)
2025-01-13 18:58:34 <pgimeno     > that's not what I'd call documenting the code
2025-01-13 18:59:08 <veltas      > "Documenting this function has been left as an exercise for the intern"
2025-01-13 19:46:28 <xentrac     > heh, I've seen a lot of schematics that are kind of like that too :-D
2025-01-13 19:47:16 <zelgomer    > x += 7;  /* add 5 to x */
2025-01-13 19:53:26 <xentrac     > #define FIVE 7
2025-01-13 19:53:33 <xentrac     > x += FIVE;  // add 5 to x
2025-01-13 19:53:54 <zelgomer    > good point: an intern would use // and not /* */
2025-01-13 19:54:13 <xentrac     > hey!
2025-01-13 19:54:20 <thrig       > / got rejected as a comment character as then ; would have been necessary for division
2025-01-13 19:54:40 <thrig       > instead, they bloated the memory of the PDP
2025-01-13 19:54:40 <xentrac     > was there some language that used %?
2025-01-13 19:55:04 <xentrac     > they could have used :- or -:
2025-01-13 19:55:26 <thrig       > two characters? yeah, no. not on the PDP
2025-01-13 19:55:42 <pgimeno     > just the percent sign? tex
2025-01-13 19:55:53 <xentrac     > aha, thanks
2025-01-13 19:56:22 <thrig       > https://en.wikipedia.org/wiki/PDP-11 and look for division
2025-01-13 19:56:38 <pgimeno     > I was checking this out to help me choose the line comment word: https://gist.github.com/dk949/88b2652284234f723decaeb84db2576c
2025-01-13 19:56:52 <xentrac     > NB. REM
2025-01-13 20:07:27 <veltas      > PDP-7 isn't it?
2025-01-13 20:08:59 <xentrac     > the PDP-7 didn't have C (or B)
2025-01-13 20:09:02 <xentrac     > just Unix
2025-01-13 20:09:28 <veltas      > B was on PDP-7 before PDP-11
2025-01-13 20:09:53 <veltas      > And PDP-11 didn't exist when it was first written
2025-01-13 21:44:29 <xentrac     > it was?
2025-01-13 21:47:40 <xentrac     > > Among other programs, the PDP-7 B cross-compiler for the PDP-11 was written in B, and in the course of time, the B compiler for the PDP-7 itself was transliterated from TMG into B. ¶ When the PDP-11 arrived, B was moved to it almost immediately. In fact, a version of the multi-precision `desk calculator' program dc was one of the earliest programs to run on the PDP-11, well before the disk arrived.
2025-01-13 21:47:46 <xentrac     > However, B did not take over instantly. Only passing thought was given to rewriting the operating system in B rather than assembler, and the same was true of most of the utilities. Even the assembler was rewritten in assembler. This approach was taken mainly because of the slowness of the interpretive code. Of smaller but still real importance was the mismatch of the word-oriented B language with the
2025-01-13 21:47:52 <xentrac     > byte-addressed PDP-11.
2025-01-13 21:47:55 <xentrac     > from <https://www.bell-labs.com/usr/dmr/www/hist.html>
2025-01-13 21:47:58 <xentrac     > thank you for the correct,ion, veltas!