<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Steve,<br><br>>After all, Dbase was an interpreter so it had to be reparsed on every execution.</div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Interpreters are separate beasts all to themselves, and I have never studied Dbase, but some interpreters keep a partial compilation around and only when the source code changes do they re-evaluate the source code.  Often interpreters are used instead of compilers because they have a lot more data around for debugging.  For example, they can actually point to the source code statement and data item that causes an overflow or other exception.<br><br>>Speaking of all that, what do you know about P-Code?<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">It has been a long time since I looked at it, but P-Code is more or less a generic term for the level of compilation that creates "atoms", which can then be executed across architectures.   All of the lexical and syntactical analysis has been done and the "atoms" are generated that normally would go to the code generator (perhaps with some high-level optimizations done first) to generate the actual architecture-specific binaries.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Imagine that each atom generated by the compiler simply calls a subroutine on the target system and that subroutine executes what the atom said to do.   This has been used by Pascal (the first time I heard of P-code), but has also been used by Java (Javabeans are the essence of this) and other systems.   A sub-class of this is what is known as "threaded interpretive languages".<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">This can create executions as fast or even faster than compiled code, as the "subroutines" can be tuned very tightly to the architecture, and very highly optimized.<br><br>>If I ever get to the point where my Stylz compiler is too slow, I'll write back to you for advice.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">It has been over thirty years since I taught compiler design, although I do take an interest from time to time in optimization techniques.<br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">When it comes to your compiler being too slow, I would first profile the complier and see where it is spending its time and why just like I would do any program.<br><br>A friend of mine, Tom Tresvik (unfortunately now deceased) took the compiler that was compiling the Ultrix kernel and put it on a RAM disk.   Reducing the I/O time from taking the source code and temporary files off the spinning disk and putting it in a RAM disk made the 24-hour compilation time of the Ultrix kernel on a VAX-11/780 to less than an hour.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">If I go on any further I might go into a deep discussion about optimizations, how important they are and how some people say that "memory is cheap, processors are fast and cores are plentiful and optimization is not really needed"....a statement <i><b>almost</b></i> as stupid as "comments slow compilation".   Actually there are many topics that people should really understand, but don't, and just thinking about these make me upset.<br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">Warmest regards,<br><br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small">maddog<br></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:small"><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 16, 2023 at 8:08 PM Steve Litt via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks maddog!<br>
<br>
I would have figured the lexical analysis would have gotten rid of the<br>
comments right away so nothing downstream had to deal with it. If I<br>
ever get to the point where my Stylz compiler is too slow, I'll write<br>
back to you for advice. Right now my level of understanding is so low<br>
that it sounds like a pipedream, but I think I can do it.<br>
<br>
Copy that on comments making trouble with paper tape and 300 baud<br>
modems. In fact, my buddy Bill who is a huge Foxbase expert, told me<br>
around 1987 that for performance reasons he had to keep variable names<br>
short in software he wrote in Dbase. After all, Dbase was an<br>
interpreter so it had to be reparsed on every execution. Ugh!<br>
<br>
Speaking of all that, what do you know about P-Code?<br>
<br>
Thanks,<br>
<br>
SteveT<br>
<br>
Jon "maddog" Hall said on Thu, 16 Nov 2023 07:43:09 -0500<br>
<br>
>Steve,<br>
><br>
>Different compilers are written in different ways, but in general you<br>
>are right.   Compared to the lexical analysis, syntactical analysis and<br>
>optimization stages (ESPECIALLY OPTIMIZATION) the tokenization stage<br>
>(which includes removing comments) is a blip in the timeline of<br>
>compilation.<br>
><br>
>I will say that comments DID have a real impact when compilers were<br>
>reading in source code on paper tape on an ASR-33 Teletype, but that<br>
>was the last time I even considered the issue oft compilation time<br>
>being slowed down by comments.<br>
><br>
>md<br>
><br>
>On Wed, Nov 15, 2023 at 10:08 PM Steve Litt via Ale <<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>><br>
>wrote:<br>
><br>
>> Jon "maddog" Hall via Ale said on Wed, 15 Nov 2023 19:28:38 -0500<br>
>>  <br>
>> >The other thing that surprised me was the passage that said<br>
>> >"Comments just slow down the compilation".<br>
>> ><br>
>> >Paaaaleese!  Even the heaviest commented source code on a compiled<br>
>> >program would be a breeze for the compiler to handle.  This excuse<br>
>> >is fake news.  <br>
>><br>
>> Maddog, is the first step, before lexical analysis, replacing all<br>
>> space characters and newlines with tokens so the lexical analyzer<br>
>> sees the program as a single string?<br>
>><br>
>> If that's the case, I can see where // to the next linefeed and /* to<br>
>> the next */ would be very fast.<br>
>><br>
>> Thanks,<br>
>><br>
>> SteveT<br>
>><br>
>> Steve Litt<br>
>><br>
>> Autumn 2023 featured book: Rapid Learning for the 21st Century<br>
>> <a href="http://www.troubleshooters.com/rl21" rel="noreferrer" target="_blank">http://www.troubleshooters.com/rl21</a><br>
>> _______________________________________________<br>
>> Ale mailing list<br>
>> <a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
>> <a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
>> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>> <a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
>>  <br>
<br>
<br>
SteveT<br>
<br>
Steve Litt <br>
<br>
Autumn 2023 featured book: Rapid Learning for the 21st Century<br>
<a href="http://www.troubleshooters.com/rl21" rel="noreferrer" target="_blank">http://www.troubleshooters.com/rl21</a><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>