Prev: James Gosling the Creator of EMACS and JAVA - leaves ORACLE - But then reports started coming in of odd failures. Systems would crash strangely. We'd get crashes in applications. All applications. Crashes in the kernel.
Next: WORK FROM YOUR HOME AWESOME EARNINGS NO INVESTMENT
From: mdj on 29 Jul 2010 23:51
On Jul 23, 4:12 pm, Fren Zeee <frenz...(a)gmail.com> wrote:
> Why is a VM needed when there is compiled C code running machine
> code ?

The are two essential reasons. Firstly, the bytecode is more compact
in memory than either the machine code or the READ lisp code.
Secondly, it loads a good deal faster from disk, allowing emacs to
start (relatively) quickly.

Thirdly, it is relatively straightforward to implement a portable
bytecode interpreter in C that will then compile on any architecture
for which one has a C compiler. This is a great deal less work than
developing a 'to-machine-code' compiler for every architecture out
there.

Keep in mind that the early releases of GNU Emacs were in the mid
1980's when personal computers powerful enough to run Emacs had
typically perhaps 1mb of RAM. Keeping the in-memory footprint of Emacs
small was more important than raw speed which would need more RAM, and
necessitate customizer the code generator for every conceivable
architecture.

In 1989 there were a LOT of 32bit microprocessor architectures out
there, and many still survive to this day.

To answer the rest of your questions, I'd recommend enrolling in a
good computer science degree.

Matt
From: Fren Zeee on 30 Jul 2010 01:01
On Jul 29, 8:51 pm, mdj <mdj....(a)gmail.com> wrote:
> On Jul 23, 4:12 pm, Fren Zeee <frenz...(a)gmail.com> wrote:
>
> > Why is a VM needed when there is compiled C code running machine
> > code ?
>
> The are two essential reasons. Firstly, the bytecode is more compact
> in memory than either the machine code or the READ lisp code.
> Secondly, it loads a good deal faster from disk, allowing emacs to
> start (relatively) quickly.

an example

preferably from an emacs file from savannah link so one could get an
idea of the animal.

theoretical reasons for speed ?

> Thirdly, it is relatively straightforward to implement a portable
> bytecode interpreter in C that will then compile on any architecture
> for which one has a C compiler. This is a great deal less work than
> developing a 'to-machine-code' compiler for every architecture out
> there.

Why is it less than porting the C compiler ? How would it be written ?
assembler ?

> Keep in mind that the early releases of GNU Emacs were in the mid
> 1980's when personal computers powerful enough to run Emacs had
> typically perhaps 1mb of RAM. Keeping the in-memory footprint of Emacs
> small was more important than raw speed which would need more RAM, and
> necessitate customizer the code generator for every conceivable
> architecture.


> In 1989 there were a LOT of 32bit microprocessor architectures out
> there, and many still survive to this day.

> To answer the rest of your questions, I'd recommend enrolling in a
> good computer science degree.

I am sure someone can point to a tutorial paper or book,

no one need you to give that obvious advice ... so obvious that i
consider rude

> Matt

From: mdj on 30 Jul 2010 01:28
On Jul 30, 3:01 pm, Fren Zeee <frenz...(a)gmail.com> wrote:
> On Jul 29, 8:51 pm, mdj <mdj....(a)gmail.com> wrote:
>
> > On Jul 23, 4:12 pm, Fren Zeee <frenz...(a)gmail.com> wrote:
>
> > > Why is a VM needed when there is compiled C code running machine
> > > code ?
>
> > The are two essential reasons. Firstly, the bytecode is more compact
> > in memory than either the machine code or the READ lisp code.
> > Secondly, it loads a good deal faster from disk, allowing emacs to
> > start (relatively) quickly.
>
> an example
>
> preferably from an emacs file from savannah link so one could get an
> idea of the animal.

Any emacs lisp source file will serve as an example.

> theoretical reasons for speed ?

bytecode is simpler to parse, and more compact in its representation
than s-expressions represented as cons cells.

> > Thirdly, it is relatively straightforward to implement a portable
> > bytecode interpreter in C that will then compile on any architecture
> > for which one has a C compiler. This is a great deal less work than
> > developing a 'to-machine-code' compiler for every architecture out
> > there.
>
> Why is it less than porting the C compiler ? How would it be written ?
> assembler ?

Are you suggesting the emacs lisp compiler could target C instead of
bytecode?

> > Keep in mind that the early releases of GNU Emacs were in the mid
> > 1980's when personal computers powerful enough to run Emacs had
> > typically perhaps 1mb of RAM. Keeping the in-memory footprint of Emacs
> > small was more important than raw speed which would need more RAM, and
> > necessitate customizer the code generator for every conceivable
> > architecture.
> > In 1989 there were a LOT of 32bit microprocessor architectures out
> > there, and many still survive to this day.
> > To answer the rest of your questions, I'd recommend enrolling in a
> > good computer science degree.
>
> I am sure someone can point to a tutorial paper or book,
>
> no one need you to give that obvious advice ... so obvious that i
> consider rude

Okay, but your relatively poor command of english is making you appear
very rude as well. Perhaps consider using more words to describe what
you mean. The odd gratuity like 'please' and 'thanks' would do wonders
for your style.


From: Fren Zeee on 30 Jul 2010 01:41
On Jul 29, 10:28 pm, mdj <mdj....(a)gmail.com> wrote:
> On Jul 30, 3:01 pm, Fren Zeee <frenz...(a)gmail.com> wrote:
>
>
>
>
>
> > On Jul 29, 8:51 pm, mdj <mdj....(a)gmail.com> wrote:
>
> > > On Jul 23, 4:12 pm, Fren Zeee <frenz...(a)gmail.com> wrote:
>
> > > > Why is a VM needed when there is compiled C code running machine
> > > > code ?
>
> > > The are two essential reasons. Firstly, the bytecode is more compact
> > > in memory than either the machine code or the READ lisp code.
> > > Secondly, it loads a good deal faster from disk, allowing emacs to
> > > start (relatively) quickly.
>
> > an example
>
> > preferably from an emacs file from savannah link so one could get an
> > idea of the animal.
>
> Any emacs lisp source file will serve as an example.
>
> > theoretical reasons for speed ?
>
> bytecode is simpler to parse, and more compact in its representation
> than s-expressions represented as cons cells.
>
> > > Thirdly, it is relatively straightforward to implement a portable
> > > bytecode interpreter in C that will then compile on any architecture
> > > for which one has a C compiler. This is a great deal less work than
> > > developing a 'to-machine-code' compiler for every architecture out
> > > there.
>
> > Why is it less than porting the C compiler ? How would it be written ?
> > assembler ?
>
> Are you suggesting the emacs lisp compiler could target C instead of
> bytecode?
>
> > > Keep in mind that the early releases of GNU Emacs were in the mid
> > > 1980's when personal computers powerful enough to run Emacs had
> > > typically perhaps 1mb of RAM. Keeping the in-memory footprint of Emacs
> > > small was more important than raw speed which would need more RAM, and
> > > necessitate customizer the code generator for every conceivable
> > > architecture.
> > > In 1989 there were a LOT of 32bit microprocessor architectures out
> > > there, and many still survive to this day.
> > > To answer the rest of your questions, I'd recommend enrolling in a
> > > good computer science degree.
>
> > I am sure someone can point to a tutorial paper or book,
>
> > no one need you to give that obvious advice ... so obvious that i
> > consider rude


> Okay, but your relatively poor command of english is making you appear
> very rude as well. Perhaps consider using more words to describe what
> you mean. The odd gratuity like 'please' and 'thanks' would do wonders
> for your style.- Hide quoted text -

If you had given a concrete example, it would have come out
automatically.

There are two pre-requisites for giving such a useful clear reply. One
is
technical competence, and another is generosity.

Its obvious that you lack one or the other so I wont get into an
argument with you.

From: Barry Margolin on 2 Aug 2010 15:35
In article
<80cc90dc-d66b-4d93-9ff9-dccacec01770(a)c10g2000yqi.googlegroups.com>,
Fren Zeee <frenzeee(a)gmail.com> wrote:

> On Jul 29, 8:51�pm, mdj <mdj....(a)gmail.com> wrote:
> > Thirdly, it is relatively straightforward to implement a portable
> > bytecode interpreter in C that will then compile on any architecture
> > for which one has a C compiler. This is a great deal less work than
> > developing a 'to-machine-code' compiler for every architecture out
> > there.
>
> Why is it less than porting the C compiler ? How would it be written ?
> assembler ?

It isn't less, it's very similar. But since someone has already done
the C compiler, you don't need to do it at all. You can simply write a
byte-code interpreter once, and it will run on all the machines that
have C compilers.

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
First  |  Prev  | 
Pages: 1 2 3
Prev: James Gosling the Creator of EMACS and JAVA - leaves ORACLE - But then reports started coming in of odd failures. Systems would crash strangely. We'd get crashes in applications. All applications. Crashes in the kernel.
Next: WORK FROM YOUR HOME AWESOME EARNINGS NO INVESTMENT