On 3/17/2017 10:07 AM, David Thatcher wrote:
Hi Jan,
I trust all is well with you and yours.
On Thu, Mar 16, 2017 at 10:14:34AM -0700, Jan Steinman wrote:
I think you should cut interpreters some slack!
In my (admittedly dated) experience, a good interpreter actually
*reduces* the memory volume that a given amount of functionality
consumes, trading it off for reduced run-time speed.
You can think of the virtual code as a fixed set of subroutines. So in
Smalltalk (for a lovely, but obsolete example), you had a library of 256
subroutines that you could call ??? some, as complicated as BITBLT,
which did all sorts of complicated image manipulation ??? all at the
cost of ONE BYTE!
You did say GOOD interpreters. :)
I've always thought the system in which I developed many apps, including one still being used by top management of a
huge company - 17 years after my retirement, was close to ideal in overall design:
Visual design of common app elements interpreted into a powerful, flexible
language.
The ability to do anything the visual design wouldn't by programming, such as
complex calculations.
Optimizing compiler to small native EXEs.
The original implementation was really good. After a merger with a maker of optimizing compilers, it got better. Just
about everything I did dealt with data, and I/O was always the speed limit.
It was possible to include all needed subroutines from the libraries in the finished app. Or, in a situation where many
programs might be running and want to share resources, compile to grab subs from a library when running.
All run time efficiencies completely moot on today's fast machines with huge 'disks' and gobs of memory, but it was
impressive on laptops of many years ago. A few other things might seem quick, until they ran OSCAR. :-)
Bloat in the interpreter subroutines
is bad, that one byte blows out to hundreds of lines of code in the
subroutine call and is just as much a pain for users as big inline code.
Having written BIOS primate functions in Z80 for homebrew CP/M-alike
system (and at one time I had a need to convert TVI912 escape codes to
VT52 on the fly in the charout call), it's easy to see how easy the
waste can grow. Sooner or later, no matter how many layers of
abstraction, the raw cpu-specific machine code *has* to be executed. If
the interpreter/virtual machine is just rubbish, we're in trouble! :)
In the true general-purpose system, even the interpreter is loaded when
required and becomes part of the memory consumption only while resident-
which reminds me of high school: putting the orange 'PACKAGE'
(Hollerith/OMR) card on top of my card stack to be sent away to the
state Ed Dept computing centre's IBM370, so I could have a calendar with
an ASCII art Snoopy (actually Einstein) on it, printed on 132 column
paper. I also chose the year 2000, it seemed so far away... it's just
about as far behind us now! We were exposed to BASIC as well - also
using OMR cards with the blue BASIC card on top of the stack, but
there's nothing worse than getting your output a week later with
'Syntax error in line 10' :)
Modern RISC processors are notorious for consuming gobs of run-time
memory. ???You want to add 1 + 1? That will cost you 96 bits, >
m???am!??? How refreshing to push two values on a stack and execute a >
single bytecode!
Yes this is true, but they do make up for it in speed. RISC is a
completely different mindset. Because of the instruction cache and the
use of branch prediction, significant savings in execution time can be
made - on average!
Another old favourite that seems to have bit the dust was FORTH.
I had no experience with FORTH,
I played with FORTH a little. Super powerful and flexible. Only useful, to my mind, for someone who did clean, careful
coding with good, immediate documentation in the code. Really easy to write something totally obscure without a magic
decoder ring.
The interpreter I really liked, and used a lot, was REXX, originally for IBM mainframe, where it was truly invaluable,
later for PCs, and still available for Windoze as part of my favorite programming editor, KEDIT.
En Coded Moose
--
What if the Hokey Pokey *IS* what it's all about?
--
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/
|