Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Aug 2001 22:20:15 -0500
From:      Mike Meyer <mwm@mired.org>
To:        Matthew Hagerty <mhagerty@voyager.net>
Cc:        Mike Meyer <mwm@mired.org>, questions@FreeBSD.ORG
Subject:   Re: just how many known viruses are there for FreeBSD?
Message-ID:  <15208.50927.720632.322670@guru.mired.org>
In-Reply-To: <5.0.2.1.2.20010801224548.018f7a38@pop.voyager.net>
References:  <14171361@toto.iv> <5.0.2.1.2.20010801224548.018f7a38@pop.voyager.net>

next in thread | previous in thread | raw e-mail | index | archive | help

Matthew Hagerty <mhagerty@voyager.net> types:
> At 08:55 PM 8/1/2001 -0500, Mike Meyer wrote:
> >Please don't top post. From Greg Lehey's tutorial on -questions at
> ><URL: http://www.lemis.com/questions.html >:
> >  9. Put your response in the correct place (after the text to which it
> >     replies). It's very difficult to read a thread of responses where each
> >     reply comes before the text to which it replies.
> >I've not bothered trying to recover the format. If things are
> >mis-attributed, flame the people who are top posting.
> >Matthew Hagerty <mhagerty@voyager.net> types:
> > > Being written in assembly has nothing to do with what a program can
> > > do!  All programs, no matter what language they are written in are either
> > > compiled or interpreted down to "machine language" in order to be executed
> > > by the processor.
> >
> >This is wrong. Interpreted programs aren't "interpreted down to
> >machine language". They may not even be "interpreted by machine
> >language", though at the bottom level that's what's going on. If the
> >distinction isn't clear to you, I'll be glad to explain further.
> 
> The distinction is very clear and is not wrong.

This is 100% correct. The problem is, your original statement failed
to make that distinction - which is why that statement is wrong.

> The interpreter was most 
> likely written in some language that was compiled, and even if it was not, 
> a high level language that is interpreted winds up as a series of calls to 
> the internals of the interpreter, which in turn executes a prepared set of 
> code, which is usually already compiled and ready for execution, i.e. a 
> shared lib, etc.  So, yes, even an interpreted language causes "machine 
> code" to be executed, every program does, they have to or they would not 
> run.  Does the interpreter make a 'print "hello world"' statement into 
> machine code, no probably not, but it certainly, eventually, causes a 
> predetermined set of machine code instructions to be executed... so what's 
> the difference?

This is a description of being executed by machine code, and it's
*not* the same thing as "interpreted down to machine code". It also
ignores the case of the interpreter being written in an interpreted
language, but that's not a difference that makes a difference.

> More often than not it is simply a matter of speed,  code 
> size, development time, copy protection, budget, knowledge or the 
> developer, and on and on.  But for the original author to say that a 
> program written in Assembly can perform things that you can't do in "high 
> level" languages is simply not true.

Whether what the original author said is true or not depends on the
high level language in question. In particular, interpreted languages
can only execute instructions from that "prepared set" you talk
about. If a specific assembly language instruction isn't in the
prepared set of instructions, then it can't be executed without an
escape mechanism of some sort. Similar comments apply to most compiled
languages, except that the code really is translated down to machine
code, instead of being selected by an interpreter.

Of course, once you use that escape mechanism, you're writing in
machine code or assembler, and using some mechanism other than an
assembler and loader to execute it.

> Your limitations are usually within 
> the language, higher-level languages usually giving more restriction, but 
> even then there are usually ways around that, i.e. peek and poke in BASIC, etc.

Peek and poke in BASIC don't let you execute instructions that aren't in the set of instructions used by the interpreter. In some BASICs, on some platforms, you can PEEK and POKE into the executable code to do that - but in other BASICs or other platforms, you can't, because the platform won't let you write to the instruction part fo the program.

	<mike
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15208.50927.720632.322670>