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. :) 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, a friend wrote an interpreter for a
small 68000 system he designed, before PCs got really cheap - he needed
more power than the old Little Big Board was able to give! To show how
small the footprint is, he even created a FORTH system using an advanced
8031 microcontroller variant in the 90's.
> In the early 80s, when most of you were huddled in caves, banging
> rocks together, typing on bended knee at the almighty ???C: ??? prompt,
> I had a full-windowing system, consistently and logically controlled by
> Doug Englebart???s new-fangled ???mouse??? ??? all in ONE MEGABYTE of
> RAM!
" A> " prompt, PLEASE ;)
My first real system was a homebrew CP/M-workalike machine (using ZDOS
and ZCPR). I still preferred to use that over my 386 PC for most basic
things! The CP/M exprience stood me in good stead for my formal
education in 8086 assembly under MS-DOS in the early 1990s.
This is back when messing around with computers and electronics was fun!
I was just cutting my teeth on valve guitar amplifiers at the time too.
Now I'm just way too nervous to poke around inside a Marshall or an
older Laney - big nasty biteys in there!!
davidt
--
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/
|