11:32:33
##forth
<veltas>
pgimeno: JAForth looks awesome, will have to read/play with later, thanks for sharing
11:33:18
##forth
<pgimeno>
oh just don't get your hopes too high, it's very JA specific, and JA has many quirks
11:34:04
##forth
<veltas>
I know that, don't worry :P
11:34:25
##forth
<pgimeno>
nice, in that case, hope you enjoy it ^.^
11:34:37
##forth
<veltas>
cheers
11:39:23
##forth
<veltas>
Is this your first venture into Forth?
11:39:51
##forth
<pgimeno>
I'd say second, if you count the previous compiler (which did not have interpreting capabilities)
11:40:15
##forth
<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
11:40:24
##forth
<veltas>
Certainly this is what I'd grab if I wrote anything for it
11:41:28
##forth
<veltas>
Talking of the Python thing anyway
11:41:47
##forth
<veltas>
It is interesting that this can be achieved in the JupiterAce emulator as well
11:42:23
##forth
<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()
11:42:44
##forth
<pgimeno>
which I believe are a bottleneck here
11:43:01
##forth
<veltas>
What's slow? The Python one? How slow are we talking?
11:43:38
##forth
<pgimeno>
the Python one, yes - I've tried it with Mazogs and it takes about 2-3 seconds to compile
11:43:52
##forth
<veltas>
That's fine IMO
11:44:19
##forth
<pgimeno>
yes, it's not fast but there isn't much need for speed given its purpose
11:45:25
##forth
<veltas>
Which do you prefer, the emulator or the Python compiler?
11:46:54
##forth
<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
11:47:47
##forth
<pgimeno>
the emulator is faster, but I am not extending it to add the extra words that the Python version has
11:48:07
##forth
<veltas>
I don't think it's harder to extend is it?
11:48:23
##forth
<veltas>
Can't you write the extra words in the native Forth and 'include' those first?
11:48:41
##forth
<veltas>
I think if the emulator was written in Python it would be slower
11:50:01
##forth
<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
11:51:24
##forth
<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
11:51:46
##forth
<pgimeno>
once the result is compiled, these are no longer useful
11:52:59
##forth
<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
11:53:05
##forth
<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
11:55:11
##forth
<veltas>
How much room is in ROM?
11:55:17
##forth
<pgimeno>
8 KB
11:55:21
##forth
<veltas>
Could you sneak them in there?
11:55:33
##forth
<veltas>
At end of the ROM part of dictionary
11:56:55
##forth
<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
11:57:28
##forth
<pgimeno>
I may have misunderstood, the ROM size is 8 KB but it's fully used
11:59:23
##forth
<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
11:59:39
##forth
<pgimeno>
words used only at compilation time
11:59:43
##forth
<veltas>
ROM trap is better
12:00:11
##forth
<pgimeno>
ROM trap is nice, but it doesn't let users write their own compilation aids, which is what I had in mind
12:00:30
##forth
<veltas>
I think you can allow that (?)
12:01:06
##forth
<veltas>
Have a special compilation word that defines a compilation-only word etc
12:01:35
##forth
<pgimeno>
yes, but words need to be in Z80-addressable memory, because every address in a word is a Z80 address
12:02:31
##forth
<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
12:03:26
##forth
<pgimeno>
that's how I came up with the idea of storing them in a higher memory area
12:04:00
##forth
<pgimeno>
JA usually comes with 1K and most users expanded it to up to 17K; 49K is rare
12:07:26
##forth
<veltas>
All this is why the python compiler is better I guess
12:09:51
##forth
<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
12:11:08
##forth
<pgimeno>
there's no ROM after all, besides the main loop and the LINE word definitions
12:19:52
##forth
<pgimeno>
also, well, the Python version makes it easier to add more internal words to the interpreter itself, being a more friendly language
12:51:21
##forth
<veltas>
I think the Python one I would consider either a cross forth, or almost a cross forth
12:51:42
##forth
<veltas>
And I think that's a good model for generating Forth images, ROM's and/or apps
16:05:43
##forth
<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
16:06:00
##forth
<KipIngram>
I agree.
16:06:25
##forth
<veltas>
No offense crc, your literate programming is quite good as far as it goes, just don't want it for myself
16:06:42
##forth
<KipIngram>
After all, mechanical drawings don't explain to you how that part meets its requirements.
16:07:15
##forth
<KipIngram>
Schematics don't tell you about the electronics theory behind the design.
16:08:20
##forth
<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
16:08:29
##forth
<veltas>
I'd never make it standard
16:10:29
##forth
<crc>
veltas: in recent times, I do a lot less literate coding, mostly now just for things I'm publishing for others to study
16:16:39
##forth
<veltas>
Makes sense
18:26:17
##forth
<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
18:27:03
##forth
<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)
18:54:06
##forth
<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.
18:54:22
##forth
<KipIngram>
But the "why" is not addressed.
18:54:34
##forth
<KipIngram>
Why did you need three bolts instead of two? Etc.
18:55:57
##forth
<xentrac>
Sometimes it is, in the comments on the schematic or print
18:56:38
##forth
<xentrac>
but often it is not
18:57:34
##forth
<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)
18:58:34
##forth
<pgimeno>
that's not what I'd call documenting the code
18:59:08
##forth
<veltas>
"Documenting this function has been left as an exercise for the intern"
19:46:28
##forth
<xentrac>
heh, I've seen a lot of schematics that are kind of like that too :-D
19:47:16
##forth
<zelgomer>
x += 7; /* add 5 to x */
19:53:26
##forth
<xentrac>
#define FIVE 7
19:53:33
##forth
<xentrac>
x += FIVE; // add 5 to x
19:53:54
##forth
<zelgomer>
good point: an intern would use // and not /* */
19:54:13
##forth
<xentrac>
hey!
19:54:20
##forth
<thrig>
/ got rejected as a comment character as then ; would have been necessary for division
19:54:40
##forth
<thrig>
instead, they bloated the memory of the PDP
19:54:40
##forth
<xentrac>
was there some language that used %?
19:55:04
##forth
<xentrac>
they could have used :- or -:
19:55:26
##forth
<thrig>
two characters? yeah, no. not on the PDP
19:55:42
##forth
<pgimeno>
just the percent sign? tex
19:55:53
##forth
<xentrac>
aha, thanks
19:56:52
##forth
<xentrac>
NB. REM
20:07:27
##forth
<veltas>
PDP-7 isn't it?
20:08:59
##forth
<xentrac>
the PDP-7 didn't have C (or B)
20:09:02
##forth
<xentrac>
just Unix
20:09:28
##forth
<veltas>
B was on PDP-7 before PDP-11
20:09:53
##forth
<veltas>
And PDP-11 didn't exist when it was first written
21:44:29
##forth
<xentrac>
it was?
21:47:40
##forth
<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.
21:47:46
##forth
<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
21:47:52
##forth
<xentrac>
byte-addressed PDP-11.
21:47:58
##forth
<xentrac>
thank you for the correct,ion, veltas!