On Mar 31, 1:12 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> Bernd Paysan <bernd.pay...@[EMAIL PROTECTED]
> wrote:
> > Stephen Pelc wrote:
> > > You don't write applications.
>
> > > Especially, you don't write large applications.
>
> > Just for comparison: On the machine I'm sitting right now, MINOS
> > (~10kloc) takes 0.1s to compile (with bigForth). MINOS can be
> > save-system'd (and the time for this is included in the 0.1s). Theseus
> > takes 0.08s to compile on top of it. The largest application so far
> > that I created with Theseus(about 5kloc), the audio amplifier GUI I
> > showed last EuroForth, takes 0.05s to compile. It takes 0.25s to
> > initialize the USB interface to talk to the device, so I've not
> > bothered with save-system-ing this part.
>
> > Yes, neither Anton nor I write 1 million line applications. It takes
> > about 10 seconds to compile a 1 million line application on a 2GHz PC
> > with bigFORTH. Gforth AFAIK compiles a bit faster than bigFORTH. For
> > historical reasons, bigFORTH's compiler is more optimized for compile
> > speed than for code speed (compared to VFX). I wanted reasonable
> > compile times on my Atari ST, which is more than a 1000 times slower
> > than a current PC. I also made quite some efforts back then to have as
> > much as possible saved with SAVESYSTEM (excluding dynamically
> > allocated memory).
>
> If you're thinking in terms of compiling applications on the spot, would
> it make sense to have a virtual file system? So you could put all your
> files into one big file and users who install it all can then have just
> two files to deal with -- the Forth system and the application file.
If they are all text files, and the text in the files is under your
control, its not hard to organize the source so that the first line is
a "file comment", containing the name of the file (possible followed
by a contiguous string of file comment lines, and requiring at least
one non-file comment line), and then if the files are concatenated, a
single pass through the file would allow writing an index file
identifying the line numbers in the master file associated with each
original source file. If you have time and date modified available,
you can use the existing index file when the index file is modified
after the master file, and regenerate the index file when the master
file is modified later.
I have been using my block comment words
[- file -]
[-- section --]
[--- subsection ---]
looking ahead to exactly that kind of system. Leading single character
punctuation in the title fields are reserved for later use, so, for
example, maybe to have a virtual subdirectory, relative to the current
actual directory:
[- / VER02/REV05 -]
in front of the concatenated text files from that subdirectory.
> I guess people who send out applications in source form and are
> concerned about piracy and such, might want some sort of obfuscator.
That's obviously not an issue that I am ever concerned with, either in
sup****t of professional work or for hobbyist programming, so I'll
defer on that to those who face the issue.
> That isn't hard to do, and results in source code that's probably about
> as hard to reverse-engineer as compiled code.
> Source code is slower to compile than to use a saved system, though it
> has to be a great big application for it to matter at all. And it's
> probably going to be bulkier. It lets you avoid the complications of
> SAVESYSTEM . Is there any other advantage?
The simplest obfuscator is compressed source using a non-standard or
obscure form for the compression algorithm or using decompression
information stored in the implementation rather than the file ... eg,
Huffman encoding with a fixed character table, and the character table
in the Forth implementation rather than the source file. If you used
the PuCrunch compression for the Commodore 64 ... easy to decompress,
hard to compress, ... with the decruncher in the Forth implementation,
that would be pretty substantially obfuscated, and would at the same
time give much smaller sources, given how well Forth source tends to
compress with a mix of LZ77 and RLE compression.
I don't think of SAVE-SYSTEM in terms of obfuscation, but in terms of
creating something for student use locked into a specific wordset with
error trapping and not having to worry about teaching them about the
extreme programming mindset. That is, the original source and free
software Forth implementation would be available for download if they
wanted it, but most students would only want the thing that they
download to work.
|
