Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eternal Hope Newsgroups: comp.lang.java.programmer Subject: Re: questions re Javascript Date: Fri, 25 Sep 2015 03:46:00 +0100 Organization: A noiseless patient Spider Lines: 58 Message-ID: References: <83722e36-4afe-4077-b936-229450613698@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 25 Sep 2015 02:43:59 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="78f381da7a0b3fb3dec18f2fc05e10ee"; logging-data="18698"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MCLRghtyAUT6tOwVZ7U2lENVU235oEHk=" User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: X-Mozilla-News-Host: news://news.eternal-september.org Cancel-Lock: sha1:jVfUYUWofcCK3t219fZJy9BH3dE= Xref: csiph.com comp.lang.java.programmer:32674 On 24/09/2015 21:58, Eric Sosman wrote: > On 9/24/2015 3:10 PM, Eternal Hope wrote: >> >> Well when I went to school (jeez, was it *that* long ago) a compiled >> language was one where the compiler took source code as input and >> produced native machine code that was directly executable on the >> underlying hardware as output. > > In -- let's see, 2015 minus 1966 that's forty-nine years -- > of writing computer programs for many machines in many languages, > I have encountered only two compilers of that description. (Most > folks would have called them "assemblers" rather than "compilers," > but an assembler is just a compiler for a particularly low-level > source language.) All the other compilers I've met have produced > some kind of intermediate output that required further processing -- > "linking" or "loading" at the very least -- before execution. You mean 'object code' I guess don't you as in the .o files produced when you compile C code but omit the linking phase ... details, the object code produced is exactly as machine specific as the resulting 'fixed up' eventual executable code, you should know this, I suspect you do. > Nearly that long ago I encountered my first microcoded machine. > Riddle me this: If compiling/linking/loading fills such a machine's > memory with instructions and starts them running, are they "native" > or are they just being interpreted by the microcode? Everything eventually relies on the microcode doedn't it RISC or CISC, what's executed *in* the processor is always microcode*, that's what processors do, execute microcode, using your argument everything and anything that isn't microcode stored in ROM 'in' the processor is interpreted. [*prehistoric oddities notwithstanding] > Also, at about that time I ran into my first emulator: It ran > on an IBM S/360 and impersonated an IBM 1620. What does this do > to your definition of "compiler?" Does the 1620's compiler cease > to be a compiler if its output is run on the emulator instead of > on the 1620 hardware? Is the emulator capable of being ru on the hardware of a different architecture without being re-compiled > And if you then run it on the 1620 again, > does the non-compiler regain its former compilerhood? > > The distinction between "compiler" and "interpreter" has been > blurred over the years, as layers of abstraction have grown deeper > and as the underlying hardware has gotten ever more "under" with > each technology generation. Nowadays, it's turtles all the way down. The only thing that's blurred here is the obfuscation emitted by your pre-processor :-) -- Laughing Spam Fritter