Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #32455 > unrolled thread
| Started by | rdelaney2001@gmail.com |
|---|---|
| First post | 2015-09-01 15:26 -0700 |
| Last post | 2015-09-24 12:04 -0400 |
| Articles | 20 on this page of 105 — 10 participants |
Back to article view | Back to comp.lang.java.programmer
questions re Javascript rdelaney2001@gmail.com - 2015-09-01 15:26 -0700
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-01 23:26 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-02 10:00 +0100
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-02 05:32 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-03 20:17 -0400
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-04 05:33 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:42 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-01 20:00 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-05 20:40 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-23 16:10 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 10:40 +0100
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 11:21 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 20:10 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:18 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:40 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 01:15 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:25 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:59 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:02 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-02 16:24 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 23:02 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 13:30 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-04 21:31 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-05 07:48 +0100
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 20:53 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:46 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:00 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:19 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:26 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-24 16:58 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 21:45 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 18:27 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:53 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:03 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:34 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:46 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:56 -0400
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 10:15 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 11:44 -0400
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 14:09 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 15:15 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:45 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:48 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 03:29 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 00:02 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 11:33 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 10:44 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:42 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:51 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:38 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:59 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:47 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:48 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:53 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:52 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:03 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:25 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:41 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:11 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:19 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:27 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 22:30 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:42 -0400
Re: Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, and compiling. Englewood Cliffs, N.J: Prentice-Hall. Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:26 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:07 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:55 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:46 -0400
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-25 05:20 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:54 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:05 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:36 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:57 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:10 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:27 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:19 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:35 -0400
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:10 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:55 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 00:48 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 20:55 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 11:17 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 12:30 +0100
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:00 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:03 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:14 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 19:59 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 17:13 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 22:15 +0000
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:07 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 16:48 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:02 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:32 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:45 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:13 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 21:58 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:34 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:35 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:51 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:00 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:17 -0400
Re: questions re Javascript Tim Slattery <tim@risingdove.com> - 2015-09-24 12:04 -0400
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2015-09-24 13:10 -0700 |
| Message-ID | <47d69c57-6ce4-4f35-9e14-a348a3fbf1f7@googlegroups.com> |
| In reply to | #32645 |
On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope wrote: > On 24/09/2015 00:10, Lew wrote: > > On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope wrote: > >> ... technically Java is also an interpreted language although > >> optimizations like Just In Time compilers tend to blur the distinction > >> somewhat. > > > > "Technically" Java is a compiled language. > > Ambiguous. Not at all. What is "javac"?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-24 19:55 -0400 |
| Message-ID | <mu22d4$scg$2@dont-email.me> |
| In reply to | #32653 |
On 9/24/2015 4:10 PM, Lew wrote: > On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope wrote: >> On 24/09/2015 00:10, Lew wrote: >>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope wrote: >>>> ... technically Java is also an interpreted language although >>>> optimizations like Just In Time compilers tend to blur the distinction >>>> somewhat. >>> >>> "Technically" Java is a compiled language. >> >> Ambiguous. > > Not at all. > > What is "javac"? > Not a compiler as known outside of the Java world. It only creates bytecode, not an executable file. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-25 00:48 +0000 |
| Message-ID | <mu25ld$cn$1@dont-email.me> |
| In reply to | #32661 |
On Thu, 24 Sep 2015 19:55:08 -0400, Jerry Stuckle wrote: > On 9/24/2015 4:10 PM, Lew wrote: >> On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope >> wrote: >>> On 24/09/2015 00:10, Lew wrote: >>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope >>>> wrote: >>>>> ... technically Java is also an interpreted language although >>>>> optimizations like Just In Time compilers tend to blur the >>>>> distinction somewhat. >>>> >>>> "Technically" Java is a compiled language. >>> >>> Ambiguous. >> >> Not at all. >> >> What is "javac"? >> >> > Not a compiler as known outside of the Java world. It only creates > bytecode, not an executable file. So, if I build a piece of hardware that executes bytecode directly the standard SDK javac, which you say isn't a compiler when run on my Linux box under the JVM, suddenly becomes a compiler when run on my new hardware? Or, If I take an ICL 1900 Cobol compiler (1900 CPUs ran hardwired instructions) and run it on a fully microcode-based ICL 2900 using DME microcode to implement the 1900 instruction set, the Cobol compiler is not a compiler any more? To be clear, in both cases I mean that the binary compiler installation package is installed and run on the first computer of the pair. The package is then installed on the second computer and run there, i.e. it is the same bit-identical binary code that runs on both machines. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-24 20:55 -0400 |
| Message-ID | <mu25v8$6dd$1@dont-email.me> |
| In reply to | #32662 |
On 9/24/2015 8:48 PM, Martin Gregorie wrote: > On Thu, 24 Sep 2015 19:55:08 -0400, Jerry Stuckle wrote: > >> On 9/24/2015 4:10 PM, Lew wrote: >>> On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope >>> wrote: >>>> On 24/09/2015 00:10, Lew wrote: >>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope >>>>> wrote: >>>>>> ... technically Java is also an interpreted language although >>>>>> optimizations like Just In Time compilers tend to blur the >>>>>> distinction somewhat. >>>>> >>>>> "Technically" Java is a compiled language. >>>> >>>> Ambiguous. >>> >>> Not at all. >>> >>> What is "javac"? >>> >>> >> Not a compiler as known outside of the Java world. It only creates >> bytecode, not an executable file. > > So, if I build a piece of hardware that executes bytecode directly the > standard SDK javac, which you say isn't a compiler when run on my Linux > box under the JVM, suddenly becomes a compiler when run on my new > hardware? > Let's see you build the hardware first. Otherwise you're just blowing hot air. > Or, If I take an ICL 1900 Cobol compiler (1900 CPUs ran hardwired > instructions) and run it on a fully microcode-based ICL 2900 using DME > microcode to implement the 1900 instruction set, the Cobol compiler is > not a compiler any more? > Microcode is not considered when discussing the native instruction set of the processor. Microcode is internal to the processor, and cannot be executed directly. Machine code can. And machine emulators are also not considered. The question is - can the instructions be executed by the processor without external programs. A microcode emulated machine can. But then nowadays, EVERY processor - including Intel/AMD chips use microcode. Even IBM mainframes back in the 70's used microcode. But that does not change the basic machine code of the processor. > To be clear, in both cases I mean that the binary compiler installation > package is installed and run on the first computer of the pair. The > package is then installed on the second computer and run there, i.e. it > is the same bit-identical binary code that runs on both machines. > > Nope, these are two entirely different things. Again - let's see you build the hardware. Then maybe we can discuss it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-25 11:17 +0000 |
| Message-ID | <mu3afq$sn3$1@dont-email.me> |
| In reply to | #32663 |
On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: > Again - let's see you build the hardware. Then maybe we can discuss it. > Its already been done. https://en.wikipedia.org/wiki/Java_processor Or, just find a Jazelle chip or Javelin device and use that. Parallax sold the Javelin. Physically they were very similar to their BS2 STAMP. However, they did that quite a while back, so it will be Java 1 or 2 at the most. There's an interesting discussion in this reference: http:// www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as though they've had at least one HW implementation running. In any case, what does seeing a hardware implementation have to do with a thread about clarifying natural language definitions and their associated semantics? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-09-25 12:30 +0100 |
| Message-ID | <mu3b4k$anl$1@dont-email.me> |
| In reply to | #32685 |
On 25/09/2015 12:17, Martin Gregorie wrote: > On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: > >> Again - let's see you build the hardware. Then maybe we can discuss it. >> > Its already been done. https://en.wikipedia.org/wiki/Java_processor > > Or, just find a Jazelle chip or Javelin device and use that. Parallax > sold the Javelin. Physically they were very similar to their BS2 STAMP. > However, they did that quite a while back, so it will be Java 1 or 2 at > the most. > > There's an interesting discussion in this reference: http:// > www.jopdesign.com/doc/jhal.pdf > I just skimmed it, but it looks as though they've had at least one HW > implementation running. > > In any case, what does seeing a hardware implementation have to do with a > thread about clarifying natural language definitions and their associated > semantics? Splutter !!! You bought it up in the first place Martin. and you haven't yet answered the quastion about how your byte code gets translated into binary numbers ... how does that happen ? -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-25 17:00 +0000 |
| Message-ID | <mu3uiu$fq4$1@dont-email.me> |
| In reply to | #32686 |
On Fri, 25 Sep 2015 12:30:22 +0100, Eternal Hope wrote: > On 25/09/2015 12:17, Martin Gregorie wrote: >> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: >> >>> Again - let's see you build the hardware. Then maybe we can discuss >>> it. >>> >> Its already been done. https://en.wikipedia.org/wiki/Java_processor >> >> Or, just find a Jazelle chip or Javelin device and use that. Parallax >> sold the Javelin. Physically they were very similar to their BS2 STAMP. >> However, they did that quite a while back, so it will be Java 1 or 2 at >> the most. >> >> There's an interesting discussion in this reference: http:// >> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as >> though they've had at least one HW implementation running. >> >> In any case, what does seeing a hardware implementation have to do with >> a thread about clarifying natural language definitions and their >> associated semantics? > > Splutter !!! > > You bought it up in the first place Martin. and you haven't yet answered > the quastion about how your byte code gets translated into binary > numbers ... how does that happen ? > How do you work that out? I did explicitly NOT make a distinction between bytecode compilers and machine code compilers: indeed GCJ can generate both. Pretty much at the start of all this, I said two things: 1) that you can define a high-level 'compiled language' as one where a program, usually known as a 'compiler', must be used to translate the human readable source code into something more computer friendly before it can be run and that an interpreted language does not have an explicit compilation step. 2) that compilers or assemblers that can directly generate executable code without the aid of a linker are rare in my experience and that I knew three cases (6800 assemblers, PL/9 and Elliott 503 Algol) of compiled languages that don't use a linker in the sense of a post-processor for compiler output. I should have included Java in this list since it too lacks an explicit linkage stage that must be completed before attempting to run the compiled code: my mistake. I suppose any system that can run relocatable binary code can let the runtime loader handle fixing up inter-module links. The JVM's loader does this and IIRC so do the loaders used by IBM's OS/400 and ICL's VME/B I have always heard the phrase 'interpreted languages' used to describe the case where source code is apparently executed directly without any explicit compilation stage. Examples are Perl, awk and command-line interpreters, e.g. bash or command.exe -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-25 14:03 -0400 |
| Message-ID | <mu42a2$8rl$1@dont-email.me> |
| In reply to | #32701 |
On 09/25/2015 01:00 PM, Martin Gregorie wrote: > On Fri, 25 Sep 2015 12:30:22 +0100, Eternal Hope wrote: > >> On 25/09/2015 12:17, Martin Gregorie wrote: >>> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: >>> >>>> Again - let's see you build the hardware. Then maybe we can discuss >>>> it. >>>> >>> Its already been done. https://en.wikipedia.org/wiki/Java_processor >>> >>> Or, just find a Jazelle chip or Javelin device and use that. Parallax >>> sold the Javelin. Physically they were very similar to their BS2 STAMP. >>> However, they did that quite a while back, so it will be Java 1 or 2 at >>> the most. >>> >>> There's an interesting discussion in this reference: http:// >>> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as >>> though they've had at least one HW implementation running. >>> >>> In any case, what does seeing a hardware implementation have to do with >>> a thread about clarifying natural language definitions and their >>> associated semantics? >> >> Splutter !!! >> >> You bought it up in the first place Martin. and you haven't yet answered >> the quastion about how your byte code gets translated into binary >> numbers ... how does that happen ? >> > How do you work that out? I did explicitly NOT make a distinction between > bytecode compilers and machine code compilers: indeed GCJ can generate > both. Pretty much at the start of all this, I said two things: > > 1) that you can define a high-level 'compiled language' as one where > a program, usually known as a 'compiler', must be used to translate > the human readable source code into something more computer friendly > before it can be run and that an interpreted language does not have > an explicit compilation step. > > 2) that compilers or assemblers that can directly generate executable > code without the aid of a linker are rare in my experience and that I > knew three cases (6800 assemblers, PL/9 and Elliott 503 Algol) of > compiled languages that don't use a linker in the sense of a > post-processor for compiler output. > > I should have included Java in this list since it too lacks an > explicit linkage stage that must be completed before attempting to > run the compiled code: my mistake. I suppose any system that can run > relocatable binary code can let the runtime loader handle fixing up > inter-module links. The JVM's loader does this and IIRC so > do the loaders used by IBM's OS/400 and ICL's VME/B > > I have always heard the phrase 'interpreted languages' used to describe > the case where source code is apparently executed directly without any > explicit compilation stage. Examples are Perl, awk and command-line > interpreters, e.g. bash or command.exe > > There are a dozen or so products described by their suppliers as C interpreters. Does this mean that C is an interpreted language? That these products are not really C language products? That somehow behind the scenes these products are really C language compilers masquerading as C interpreters? Something else? Does it make sense to declare a language as only either a compiled language or an interpreted language? Are there any programming languages that one strictly cannot compile or interpret? Somehow it makes more sense to me to say that a particular programming language is usually compiled to some form of native machine language, or is more usually interpreted by some virtual machine running on a native machine. I'm by far no C expert but I do seem to recall a C standard somehow referring to a virtual machine.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-25 14:14 -0400 |
| Message-ID | <mu42tb$b0t$1@dont-email.me> |
| In reply to | #32703 |
On 09/25/2015 02:03 PM, Jeff Higgins wrote: > On 09/25/2015 01:00 PM, Martin Gregorie wrote: >> On Fri, 25 Sep 2015 12:30:22 +0100, Eternal Hope wrote: >> >>> On 25/09/2015 12:17, Martin Gregorie wrote: >>>> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: >>>> >>>>> Again - let's see you build the hardware. Then maybe we can discuss >>>>> it. >>>>> >>>> Its already been done. https://en.wikipedia.org/wiki/Java_processor >>>> >>>> Or, just find a Jazelle chip or Javelin device and use that. Parallax >>>> sold the Javelin. Physically they were very similar to their BS2 STAMP. >>>> However, they did that quite a while back, so it will be Java 1 or 2 at >>>> the most. >>>> >>>> There's an interesting discussion in this reference: http:// >>>> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as >>>> though they've had at least one HW implementation running. >>>> >>>> In any case, what does seeing a hardware implementation have to do with >>>> a thread about clarifying natural language definitions and their >>>> associated semantics? >>> >>> Splutter !!! >>> >>> You bought it up in the first place Martin. and you haven't yet answered >>> the quastion about how your byte code gets translated into binary >>> numbers ... how does that happen ? >>> >> How do you work that out? I did explicitly NOT make a distinction between >> bytecode compilers and machine code compilers: indeed GCJ can generate >> both. Pretty much at the start of all this, I said two things: >> >> 1) that you can define a high-level 'compiled language' as one where >> a program, usually known as a 'compiler', must be used to translate >> the human readable source code into something more computer friendly >> before it can be run and that an interpreted language does not have >> an explicit compilation step. >> >> 2) that compilers or assemblers that can directly generate executable >> code without the aid of a linker are rare in my experience and that I >> knew three cases (6800 assemblers, PL/9 and Elliott 503 Algol) of >> compiled languages that don't use a linker in the sense of a >> post-processor for compiler output. >> >> I should have included Java in this list since it too lacks an >> explicit linkage stage that must be completed before attempting to >> run the compiled code: my mistake. I suppose any system that can run >> relocatable binary code can let the runtime loader handle fixing up >> inter-module links. The JVM's loader does this and IIRC so >> do the loaders used by IBM's OS/400 and ICL's VME/B >> >> I have always heard the phrase 'interpreted languages' used to describe >> the case where source code is apparently executed directly without any >> explicit compilation stage. Examples are Perl, awk and command-line >> interpreters, e.g. bash or command.exe >> >> > There are a dozen or so products described by their suppliers as > C interpreters. Does this mean that C is an interpreted language? > That these products are not really C language products? That somehow > behind the scenes these products are really C language compilers > masquerading as C interpreters? Something else? Does it make sense to > declare a language as only either a compiled language or an interpreted > language? Are there any programming languages that one strictly cannot > compile or interpret? Somehow it makes more sense to me to say that a > particular programming language is usually compiled to some form of native > machine language, or is more usually interpreted by some virtual machine > running on a native machine. I'm by far no C expert but I do seem to recall > a C standard somehow referring to a virtual machine. > How does LLVM fit into this compiler/interpreter classification scheme?
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-25 19:59 +0000 |
| Message-ID | <mu493n$4ur$1@dont-email.me> |
| In reply to | #32703 |
On Fri, 25 Sep 2015 14:03:55 -0400, Jeff Higgins wrote:
> On 09/25/2015 01:00 PM, Martin Gregorie wrote:
>> On Fri, 25 Sep 2015 12:30:22 +0100, Eternal Hope wrote:
>>
>>> On 25/09/2015 12:17, Martin Gregorie wrote:
>>>> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote:
>>>>
>>>>> Again - let's see you build the hardware. Then maybe we can discuss
>>>>> it.
>>>>>
>>>> Its already been done. https://en.wikipedia.org/wiki/Java_processor
>>>>
>>>> Or, just find a Jazelle chip or Javelin device and use that. Parallax
>>>> sold the Javelin. Physically they were very similar to their BS2
>>>> STAMP.
>>>> However, they did that quite a while back, so it will be Java 1 or 2
>>>> at the most.
>>>>
>>>> There's an interesting discussion in this reference: http://
>>>> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as
>>>> though they've had at least one HW implementation running.
>>>>
>>>> In any case, what does seeing a hardware implementation have to do
>>>> with a thread about clarifying natural language definitions and their
>>>> associated semantics?
>>>
>>> Splutter !!!
>>>
>>> You bought it up in the first place Martin. and you haven't yet
>>> answered the quastion about how your byte code gets translated into
>>> binary numbers ... how does that happen ?
>>>
>> How do you work that out? I did explicitly NOT make a distinction
>> between bytecode compilers and machine code compilers: indeed GCJ can
>> generate both. Pretty much at the start of all this, I said two things:
>>
>> 1) that you can define a high-level 'compiled language' as one where
>> a program, usually known as a 'compiler', must be used to translate
>> the human readable source code into something more computer
>> friendly before it can be run and that an interpreted language does
>> not have an explicit compilation step.
>>
>> 2) that compilers or assemblers that can directly generate executable
>> code without the aid of a linker are rare in my experience and that
>> I knew three cases (6800 assemblers, PL/9 and Elliott 503 Algol) of
>> compiled languages that don't use a linker in the sense of a
>> post-processor for compiler output.
>>
>> I should have included Java in this list since it too lacks an
>> explicit linkage stage that must be completed before attempting to
>> run the compiled code: my mistake. I suppose any system that can
>> run relocatable binary code can let the runtime loader handle
>> fixing up inter-module links. The JVM's loader does this and IIRC
>> so do the loaders used by IBM's OS/400 and ICL's VME/B
>>
>> I have always heard the phrase 'interpreted languages' used to describe
>> the case where source code is apparently executed directly without any
>> explicit compilation stage. Examples are Perl, awk and command-line
>> interpreters, e.g. bash or command.exe
>>
>>
> There are a dozen or so products described by their suppliers as C
> interpreters. Does this mean that C is an interpreted language?
>
The common C versions (K&R C, ANSI C and its derivative, C++) are
definitely compiled languages using a complex, multi-phase compiler.
'cc' itself is just a shell to run the appropriate compilation phases in
the required order:
- preprocessor (a macrogenerator: it expands macro definitions,
and #defines, uses #ifdef statements to control what
parts of the source files are fed to the compiler
- assembly language generator (translates C source to the native
assembler)
- optimiser (applies the requested optimisations (inlining code,
unrolling loops etc)
- assembler
- linker
How much of this you're aware of during a compilation depends on the
actual compiler. For instance:
- GNU C looks and acts like a single unitary slab most of the time
- Microware K&R C compiler for OS-9 showed all the phases as they
were run.
- most Unices, which include Linux and BSD, also have the 'ar' tool,
which is used to build code libraries, and 'make', which does much
the same job as 'ant'.
Other OSen have equivalent tools.
However, there is an interpreted language, Tiny C, which is purely
interpreted. It dates from the time when an Intel 8080 was considered a
desirable mpu. Tiny C was really an IDE, being a combined
editor,compiler,interpreter - in short, very similar to a traditional
BASIC.
Tiny C claimed to be a very small (integer) subset of C, but in fact
doesn't look a lot like it. Here's 'hello World' in tiny C:
hello-world [
pl "Hello, world"
]
and here's the equivalent in ANSI C:
/* HELLO.C - compiler test piece */
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello, C world\n");
return(0);
}
> That these products are not really C language products?
>
Does Tiny C look anything like the product you were thinking of?
> That somehow behind the scenes these products are really C
> language compilers masquerading as C interpreters?
>
I would say not, though of course people can and do use Eclipse for C
development, which would make it all look a lot different from the way I
develop C. But then, I develop C using a traditional multi-buffered
editor (microEmacs) plus make, GNU C ar and cvs for version control. I
run the lot from two or three console windows and command lines.
> Something else? Does it make sense to
> declare a language as only either a compiled language or an interpreted
> language?
>
I think mostly yes, if only because interpreted languages tend to be much
terser and use untyped variables both of which make them easier and
quicker to enter and edit.
> Are there any programming languages that one strictly cannot
> compile or interpret?
>
Don't know. Strongly typed languages may be a pain to interpret line by
line as they're entered (think JOSS or Forth here) simply because you'll
probably have to enter the whole program and enter 'RUN' before type
mismatches etc get found and reported.
I have a feeling that the ones that claim to be both will be organised
rather like traditional BASIC or Python, i.e. a combination of editor/IDE,
P-code compiler and interpreter. If you run these in interactive mode
they just a source editor until you enter the RUN command to cause a
compile-and-go. If the compile is successful, the program is run and
after it ends or fails you're back in the editor. If you run it as a
command (basic myprog.bas) then it will read in the file, do a command-
and-go and return errors and/or results to the console.
> Somehow it makes more sense to me to say that a
> particular programming language is usually compiled to some form of
> native machine language, or is more usually interpreted by some virtual
> machine running on a native machine. I'm by far no C expert but I do
> seem to recall a C standard somehow referring to a virtual machine.
>
Agreed. Those that work both ways are fairly rare, especially if they
aren't IDE-like. Sorry to keep dragging up old systems, but about the
only ones, apart from various BASICs and JOSS, that worked this way that
I know about were the command processors for ICL's VME/B and IBM's
OS/400 operating systems. Both worked similarly and both used strongly
typed command languages, so error detection was excellent:
- If you typed in a command it ran it and prompted for another
- if you entered the command name and hit a special key, you got a
fullscreen prompt showing command names and boxes alongside each to
fill in. Default values were shown and could be overtyped.
Hitting ENTER ran the completed command.
- if you started an editor and used it to write a command script,
you set up a header with argument names, types and defaults, typed
in the commands, loops and conditionals etc and closed the file.
Under OS/400 you compiled it by running CRTCLPGM and fixed errors
like any other program before you could run your new command.
CRTCLPGM looks horrid but is a shortened form of "Create Command
Language Program" but is easier to remember than you'd expect. Yes,
CRTCPGM was the C compiler and CRTPLIPGM was the PL/I compiler.
Under VME/B you simply issued the filename as a command, which tried
a compile-and-go. If it compiled, it would run. If not, you fixed
errors and tried again.
Under both OS/400 and VME/B your new command worked just like a built-in
one: you could run it from a command line, cause it to do a full screen
prompt for arguments, or call it from another command file.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-25 17:13 -0400 |
| Message-ID | <mu4dde$ls4$1@dont-email.me> |
| In reply to | #32707 |
On 09/25/2015 03:59 PM, Martin Gregorie wrote:
> On Fri, 25 Sep 2015 14:03:55 -0400, Jeff Higgins wrote:
>
>> On 09/25/2015 01:00 PM, Martin Gregorie wrote:
>>> On Fri, 25 Sep 2015 12:30:22 +0100, Eternal Hope wrote:
>>>
>>>> On 25/09/2015 12:17, Martin Gregorie wrote:
>>>>> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote:
>>>>>
>>>>>> Again - let's see you build the hardware. Then maybe we can discuss
>>>>>> it.
>>>>>>
>>>>> Its already been done. https://en.wikipedia.org/wiki/Java_processor
>>>>>
>>>>> Or, just find a Jazelle chip or Javelin device and use that. Parallax
>>>>> sold the Javelin. Physically they were very similar to their BS2
>>>>> STAMP.
>>>>> However, they did that quite a while back, so it will be Java 1 or 2
>>>>> at the most.
>>>>>
>>>>> There's an interesting discussion in this reference: http://
>>>>> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as
>>>>> though they've had at least one HW implementation running.
>>>>>
>>>>> In any case, what does seeing a hardware implementation have to do
>>>>> with a thread about clarifying natural language definitions and their
>>>>> associated semantics?
>>>>
>>>> Splutter !!!
>>>>
>>>> You bought it up in the first place Martin. and you haven't yet
>>>> answered the quastion about how your byte code gets translated into
>>>> binary numbers ... how does that happen ?
>>>>
>>> How do you work that out? I did explicitly NOT make a distinction
>>> between bytecode compilers and machine code compilers: indeed GCJ can
>>> generate both. Pretty much at the start of all this, I said two things:
>>>
>>> 1) that you can define a high-level 'compiled language' as one where
>>> a program, usually known as a 'compiler', must be used to translate
>>> the human readable source code into something more computer
>>> friendly before it can be run and that an interpreted language does
>>> not have an explicit compilation step.
>>>
>>> 2) that compilers or assemblers that can directly generate executable
>>> code without the aid of a linker are rare in my experience and that
>>> I knew three cases (6800 assemblers, PL/9 and Elliott 503 Algol) of
>>> compiled languages that don't use a linker in the sense of a
>>> post-processor for compiler output.
>>>
>>> I should have included Java in this list since it too lacks an
>>> explicit linkage stage that must be completed before attempting to
>>> run the compiled code: my mistake. I suppose any system that can
>>> run relocatable binary code can let the runtime loader handle
>>> fixing up inter-module links. The JVM's loader does this and IIRC
>>> so do the loaders used by IBM's OS/400 and ICL's VME/B
>>>
>>> I have always heard the phrase 'interpreted languages' used to describe
>>> the case where source code is apparently executed directly without any
>>> explicit compilation stage. Examples are Perl, awk and command-line
>>> interpreters, e.g. bash or command.exe
>>>
>>>
>> There are a dozen or so products described by their suppliers as C
>> interpreters. Does this mean that C is an interpreted language?
>>
> The common C versions (K&R C, ANSI C and its derivative, C++) are
> definitely compiled languages using a complex, multi-phase compiler.
> 'cc' itself is just a shell to run the appropriate compilation phases in
> the required order:
> - preprocessor (a macrogenerator: it expands macro definitions,
> and #defines, uses #ifdef statements to control what
> parts of the source files are fed to the compiler
> - assembly language generator (translates C source to the native
> assembler)
> - optimiser (applies the requested optimisations (inlining code,
> unrolling loops etc)
> - assembler
> - linker
>
> How much of this you're aware of during a compilation depends on the
> actual compiler. For instance:
>
> - GNU C looks and acts like a single unitary slab most of the time
>
> - Microware K&R C compiler for OS-9 showed all the phases as they
> were run.
>
> - most Unices, which include Linux and BSD, also have the 'ar' tool,
> which is used to build code libraries, and 'make', which does much
> the same job as 'ant'.
>
> Other OSen have equivalent tools.
>
> However, there is an interpreted language, Tiny C, which is purely
> interpreted. It dates from the time when an Intel 8080 was considered a
> desirable mpu. Tiny C was really an IDE, being a combined
> editor,compiler,interpreter - in short, very similar to a traditional
> BASIC.
>
> Tiny C claimed to be a very small (integer) subset of C, but in fact
> doesn't look a lot like it. Here's 'hello World' in tiny C:
>
> hello-world [
> pl "Hello, world"
> ]
>
> and here's the equivalent in ANSI C:
>
> /* HELLO.C - compiler test piece */
>
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
> printf("Hello, C world\n");
> return(0);
> }
>
>> That these products are not really C language products?
>>
> Does Tiny C look anything like the product you were thinking of?
Well if it will not interpret the C language then no.
The first hit for c+interpreter was
"Ch is a C/C++ interpreter and scripting language environment"
<https://www.softintegration.com/>
Which promises: from a command shell on several operating systems
Ch supports all features in the ISO C standard called C90 which was ratified
in 1990.
#include <stdio.h>
int main() {
printf("Hello, world\n");
return 0;
}
The output is: Hello, world
>
>> That somehow behind the scenes these products are really C
>> language compilers masquerading as C interpreters?
>>
> I would say not, though of course people can and do use Eclipse for C
> development, which would make it all look a lot different from the way I
> develop C. But then, I develop C using a traditional multi-buffered
> editor (microEmacs) plus make, GNU C ar and cvs for version control. I
> run the lot from two or three console windows and command lines.
>
>> Something else? Does it make sense to
>> declare a language as only either a compiled language or an interpreted
>> language?
>>
> I think mostly yes, if only because interpreted languages tend to be much
> terser and use untyped variables both of which make them easier and
> quicker to enter and edit.
I guess that it might make sense as a matter of convenience.
I suppose I am most put-off by such absolute statements as
Java is a compiled language.
Java is an interpreted language.
Clearly one could produce a compiler that outputs an executable
ELF, COFF or whatever.
And a you pointed out there have been working examples of
systems on a chip that would run bytecode from a Jave bytecode
compiler.
Java language source code interpreted line by line?
Not so sure of that, but Java 9 promises an REPL.
Interpretation of HLL code line by line by some shell is a definition of
interpretation? Some others in this thread have stated their definition
of interpretation as the output of Javac running in a JVM.
>
>> Are there any programming languages that one strictly cannot
>> compile or interpret?
>>
> Don't know. Strongly typed languages may be a pain to interpret line by
> line as they're entered (think JOSS or Forth here) simply because you'll
> probably have to enter the whole program and enter 'RUN' before type
> mismatches etc get found and reported.
>
> I have a feeling that the ones that claim to be both will be organised
> rather like traditional BASIC or Python, i.e. a combination of editor/IDE,
> P-code compiler and interpreter. If you run these in interactive mode
> they just a source editor until you enter the RUN command to cause a
> compile-and-go. If the compile is successful, the program is run and
> after it ends or fails you're back in the editor. If you run it as a
> command (basic myprog.bas) then it will read in the file, do a command-
> and-go and return errors and/or results to the console.
>
>> Somehow it makes more sense to me to say that a
>> particular programming language is usually compiled to some form of
>> native machine language, or is more usually interpreted by some virtual
>> machine running on a native machine. I'm by far no C expert but I do
>> seem to recall a C standard somehow referring to a virtual machine.
>>
> Agreed. Those that work both ways are fairly rare, especially if they
> aren't IDE-like. Sorry to keep dragging up old systems, but about the
> only ones, apart from various BASICs and JOSS, that worked this way that
> I know about were the command processors for ICL's VME/B and IBM's
> OS/400 operating systems. Both worked similarly and both used strongly
> typed command languages, so error detection was excellent:
>
> - If you typed in a command it ran it and prompted for another
>
> - if you entered the command name and hit a special key, you got a
> fullscreen prompt showing command names and boxes alongside each to
> fill in. Default values were shown and could be overtyped.
> Hitting ENTER ran the completed command.
>
> - if you started an editor and used it to write a command script,
> you set up a header with argument names, types and defaults, typed
> in the commands, loops and conditionals etc and closed the file.
>
> Under OS/400 you compiled it by running CRTCLPGM and fixed errors
> like any other program before you could run your new command.
> CRTCLPGM looks horrid but is a shortened form of "Create Command
> Language Program" but is easier to remember than you'd expect. Yes,
> CRTCPGM was the C compiler and CRTPLIPGM was the PL/I compiler.
>
> Under VME/B you simply issued the filename as a command, which tried
> a compile-and-go. If it compiled, it would run. If not, you fixed
> errors and tried again.
>
> Under both OS/400 and VME/B your new command worked just like a built-in
> one: you could run it from a command line, cause it to do a full screen
> prompt for arguments, or call it from another command file.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-25 22:15 +0000 |
| Message-ID | <mu4h2e$saq$1@dont-email.me> |
| In reply to | #32709 |
On Fri, 25 Sep 2015 17:13:27 -0400, Jeff Higgins wrote:
> On 09/25/2015 03:59 PM, Martin Gregorie wrote:
>> However, there is an interpreted language, Tiny C, which is purely
>> interpreted. It dates from the time when an Intel 8080 was considered a
>> desirable mpu. Tiny C was really an IDE, being a combined
>> editor,compiler,interpreter - in short, very similar to a traditional
>> BASIC.
>>
>> Tiny C claimed to be a very small (integer) subset of C, but in fact
>> doesn't look a lot like it. Here's 'hello World' in tiny C:
>>
>> hello-world [
>> pl "Hello, world"
>> ]
>>
>
This is the Tiny C I was describing, which is a pure interpreter:
http://primepuzzle.com/tiny-c/tinyc-doc.html
However, there's another Tiny C which is just a very fast compiler and is
not an interpreter. It only generates X86 code, claims near ISO C99
conformance, that no assembly or linking is needed. I first found it here:
http://bellard.org/tcc/
but this looks to be the motherlode:
http://savannah.nongnu.org/projects/tinycc
> Interpretation of HLL code line by line by some shell is a definition of
> interpretation? Some others in this thread have stated their definition
> of interpretation as the output of Javac running in a JVM.
>
Not necessarily so.
AFAICT almost all the modern interpreters are really "compile&go"
systems, which is how Perl or awk work, with the compile phase generating
some sort of task-related P-code that can be executed so fast that, even
with the compilation/translation preliminary, this approach executes much
faster than line-by-line iterative source interpretation ever could.
BTW, note that the Savannah project's TCC compiler (the one you found)
also falls into this category because they claim that a shell script like
this:
#!/usr/local/bin/tcc -run
#include <stdio.h>
int main() {
printf("Hello, world\n");
return 0;
}
would be perceived to run at a similar seed to, say:
#!/bin/bash
echo "Hello World"
However, TCC is a just a very fast compilation system, not an interpreter.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2015-10-02 13:07 -0700 |
| Message-ID | <5370e588-d72e-4396-b657-7e714db36c77@googlegroups.com> |
| In reply to | #32686 |
On Friday, September 25, 2015 at 4:30:30 AM UTC-7, Eternal Hope wrote: > On 25/09/2015 12:17, Martin Gregorie wrote: > > On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: > > > >> Again - let's see you build the hardware. Then maybe we can discuss it. > >> > > Its already been done. https://en.wikipedia.org/wiki/Java_processor > > > > Or, just find a Jazelle chip or Javelin device and use that. Parallax > > sold the Javelin. Physically they were very similar to their BS2 STAMP. > > However, they did that quite a while back, so it will be Java 1 or 2 at > > the most. > > > > There's an interesting discussion in this reference: http:// > > www.jopdesign.com/doc/jhal.pdf > > I just skimmed it, but it looks as though they've had at least one HW > > implementation running. > > > > In any case, what does seeing a hardware implementation have to do with a > > thread about clarifying natural language definitions and their associated > > semantics? > > Splutter !!! > > You bought it up in the first place Martin. and you haven't yet answered > the quastion about how your byte code gets translated into binary > numbers ... how does that happen ? Bytecode is interpreted. But that wasn't the question. The question was whether Java is interpreted. It isn't; it is compiled. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-10-03 16:48 +0100 |
| Message-ID | <muot7k$qms$1@dont-email.me> |
| In reply to | #32763 |
On 02/10/2015 21:07, Lew wrote: > On Friday, September 25, 2015 at 4:30:30 AM UTC-7, Eternal Hope wrote: >> On 25/09/2015 12:17, Martin Gregorie wrote: >>> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: >>> >>>> Again - let's see you build the hardware. Then maybe we can discuss it. >>>> >>> Its already been done. https://en.wikipedia.org/wiki/Java_processor >>> >>> Or, just find a Jazelle chip or Javelin device and use that. Parallax >>> sold the Javelin. Physically they were very similar to their BS2 STAMP. >>> However, they did that quite a while back, so it will be Java 1 or 2 at >>> the most. >>> >>> There's an interesting discussion in this reference: http:// >>> www.jopdesign.com/doc/jhal.pdf >>> I just skimmed it, but it looks as though they've had at least one HW >>> implementation running. >>> >>> In any case, what does seeing a hardware implementation have to do with a >>> thread about clarifying natural language definitions and their associated >>> semantics? >> >> Splutter !!! >> >> You bought it up in the first place Martin. and you haven't yet answered >> the quastion about how your byte code gets translated into binary >> numbers ... how does that happen ? > > Bytecode is interpreted. But that wasn't the question. The question was whether Java is interpreted. It isn't; it is compiled. Don't you ever get bored of being wrong? In fact, I'm not sure you are the Lew we all ... know You know, the one who's usual answer to a question is RTFM. Now Lew can be ... difficult to say the least but he/she/it did often display a certain level of knowledge of Java. You on the other hand ... are you a nym thief/shifter. Are you using an established nym as a sock puppet to some end. -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-25 10:02 -0400 |
| Message-ID | <mu3k10$dep$3@dont-email.me> |
| In reply to | #32685 |
On 9/25/2015 7:17 AM, Martin Gregorie wrote: > On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: > >> Again - let's see you build the hardware. Then maybe we can discuss it. >> > Its already been done. https://en.wikipedia.org/wiki/Java_processor > > Or, just find a Jazelle chip or Javelin device and use that. Parallax > sold the Javelin. Physically they were very similar to their BS2 STAMP. > However, they did that quite a while back, so it will be Java 1 or 2 at > the most. > > There's an interesting discussion in this reference: http:// > www.jopdesign.com/doc/jhal.pdf > I just skimmed it, but it looks as though they've had at least one HW > implementation running. > > In any case, what does seeing a hardware implementation have to do with a > thread about clarifying natural language definitions and their associated > semantics? > > That's fine. If the .class file runs natively on that chip, then I would consider it not being interpreted *on that chip*. The question here is, though. Are these chips native java, or emulators? I haven't looked at them. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-25 17:32 +0000 |
| Message-ID | <mu40g2$fq4$2@dont-email.me> |
| In reply to | #32691 |
On Fri, 25 Sep 2015 10:02:01 -0400, Jerry Stuckle wrote: > On 9/25/2015 7:17 AM, Martin Gregorie wrote: >> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: >> >>> Again - let's see you build the hardware. Then maybe we can discuss >>> it. >>> >> Its already been done. https://en.wikipedia.org/wiki/Java_processor >> >> Or, just find a Jazelle chip or Javelin device and use that. Parallax >> sold the Javelin. Physically they were very similar to their BS2 STAMP. >> However, they did that quite a while back, so it will be Java 1 or 2 at >> the most. >> >> There's an interesting discussion in this reference: http:// >> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as >> though they've had at least one HW implementation running. >> >> In any case, what does seeing a hardware implementation have to do with >> a thread about clarifying natural language definitions and their >> associated semantics? >> >> >> > That's fine. If the .class file runs natively on that chip, then I > would consider it not being interpreted *on that chip*. > > The question here is, though. Are these chips native java, or > emulators? I haven't looked at them. To the best of my knowledge the Javelin chip ran native Java, though it seemed to be somewhat feature-poor. I never got one, though I considered it, because it was a lot more pricey than the BS2 devices, but both Javelin and BS2 seemed to use very similar support software and physical set-ups. I did a fair amount with the BS2, though. Physically these are a tiny PCB carrying surface-mount chips and with 24 pins round the edges so it fit in a 24 pin DIL socket. The chips are a PIC processor executing BASIC run- time firmware, 2KB of EEPROM, and 32 bytes(!) of RAM. To program it you run an IDE on a Windows box which lets you edit and compile a real-time integer BASIC and load it into the BS2 over a serial link. Issuing a RUN command from the IDE or (with it disconnected) powering on the BS2 caused it to execute the BASIC program you'd previously loaded. There's no documentation for the compiler output, so I don't know whether the compiler emits PIC instructions or P-code: either way it manages to fit 500 Integer BASIC instructions into 2KB of EEPROM The runtime lets you treat its 8 i/o pins as digital or serial lines. No interrupts, though. All the Javelin docs have now vanished from the website, but IIRC its capabilities were similar - its just that you programmed it in 'integer Java' rather than integer BASIC. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-09-25 03:45 +0100 |
| Message-ID | <mu2cc6$i5a$1@dont-email.me> |
| In reply to | #32662 |
On 25/09/2015 01:48, Martin Gregorie wrote: > On Thu, 24 Sep 2015 19:55:08 -0400, Jerry Stuckle wrote: > >> On 9/24/2015 4:10 PM, Lew wrote: >>> On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope >>> wrote: >>>> On 24/09/2015 00:10, Lew wrote: >>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope >>>>> wrote: >>>>>> ... technically Java is also an interpreted language although >>>>>> optimizations like Just In Time compilers tend to blur the >>>>>> distinction somewhat. >>>>> >>>>> "Technically" Java is a compiled language. >>>> >>>> Ambiguous. >>> >>> Not at all. >>> >>> What is "javac"? >>> >>> >> Not a compiler as known outside of the Java world. It only creates >> bytecode, not an executable file. > > So, if I build a piece of hardware that executes bytecode directly the > standard SDK javac, We've been here before haven't we Even if you build your own hardware, eventually everything comes down to the fact that logic gates use binary input. How would you design a NAND gate that takes two bytecode instructions and produces ... what exactly, another bytecode? that's Interpretation. Binary output that is used as input to another gate? that's some gate you have there how many can you fit on a chip. Most of us here should know that in the end, everthing gets passed through the adder which can only add 2 binary numbers together 1 bit, 7 bits, 32 bits, 64bits, 2**n bits, it's all the same in the end. I don't really understand the point of this thread now, we all know that a Java translator (I'm going to call it that, 'compiler' seems to get people all upset) takes human readable source core and 'translates' (or compiles) it into byte code which is then interpreted by ... yep, an interpreter. Anything else is subersive propaganda. Even Lew knows this (assumption) and he/she/it must have been partcularly bored when he/she/it posted his/her/it's latest bizarre rant. > which you say isn't a compiler when run on my Linux > box under the JVM, suddenly becomes a compiler when run on my new > hardware? > > Or, If I take an ICL 1900 Cobol compiler (1900 CPUs ran hardwired > instructions) and run it on a fully microcode-based ICL 2900 using DME > microcode to implement the 1900 instruction set, the Cobol compiler is > not a compiler any more? > > To be clear, in both cases I mean that the binary compiler installation > package is installed and run on the first computer of the pair. The > package is then installed on the second computer and run there, i.e. it > is the same bit-identical binary code that runs on both machines. > > -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-25 10:13 -0400 |
| Message-ID | <mu3klm$hfb$1@dont-email.me> |
| In reply to | #32673 |
On 9/24/2015 10:45 PM, Eternal Hope wrote: > On 25/09/2015 01:48, Martin Gregorie wrote: >> On Thu, 24 Sep 2015 19:55:08 -0400, Jerry Stuckle wrote: >> >>> On 9/24/2015 4:10 PM, Lew wrote: >>>> On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope >>>> wrote: >>>>> On 24/09/2015 00:10, Lew wrote: >>>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope >>>>>> wrote: >>>>>>> ... technically Java is also an interpreted language although >>>>>>> optimizations like Just In Time compilers tend to blur the >>>>>>> distinction somewhat. >>>>>> >>>>>> "Technically" Java is a compiled language. >>>>> >>>>> Ambiguous. >>>> >>>> Not at all. >>>> >>>> What is "javac"? >>>> >>>> >>> Not a compiler as known outside of the Java world. It only creates >>> bytecode, not an executable file. >> >> So, if I build a piece of hardware that executes bytecode directly the >> standard SDK javac, > > We've been here before haven't we > Even if you build your own hardware, eventually everything comes down to > the fact that logic gates use binary input. How would you design a NAND > gate that takes two bytecode instructions and produces ... what exactly, > another bytecode? that's Interpretation. Binary output that is used as > input to another gate? that's some gate you have there how many can you > fit on a chip. Most of us here should know that in the end, everthing > gets passed through the adder which can only add 2 binary numbers > together 1 bit, 7 bits, 32 bits, 64bits, 2**n bits, it's all the same in > the end. > Actually, it could be done. After all, java byte code is just 1's and 0's, no different than any other file. And gates work on 1's and 0's - it would be theoretically possible to build a processor with just gates which could process jbc directly. However, it would be much easier to build a processor which had microcode to do it. The difference here is that the microcode is internal to the processor and not available (or even known) to the user. > I don't really understand the point of this thread now, we all know that > a Java translator (I'm going to call it that, 'compiler' seems to get > people all upset) takes human readable source core and 'translates' (or > compiles) it into byte code which is then interpreted by ... yep, an > interpreter. Anything else is subersive propaganda. Even Lew knows this > (assumption) and he/she/it must have been partcularly bored when > he/she/it posted his/her/it's latest bizarre rant. > Yes, translator would be a better description. >> which you say isn't a compiler when run on my Linux >> box under the JVM, suddenly becomes a compiler when run on my new >> hardware? >> >> Or, If I take an ICL 1900 Cobol compiler (1900 CPUs ran hardwired >> instructions) and run it on a fully microcode-based ICL 2900 using DME >> microcode to implement the 1900 instruction set, the Cobol compiler is >> not a compiler any more? >> >> To be clear, in both cases I mean that the binary compiler installation >> package is installed and run on the first computer of the pair. The >> package is then installed on the second computer and run there, i.e. it >> is the same bit-identical binary code that runs on both machines. >> >> > > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-24 21:58 -0400 |
| Message-ID | <mu29nj$hq8$1@speranza.aioe.org> |
| In reply to | #32661 |
On 9/24/2015 7:55 PM, Jerry Stuckle wrote: > On 9/24/2015 4:10 PM, Lew wrote: >> On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope wrote: >>> On 24/09/2015 00:10, Lew wrote: >>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope wrote: >>>>> ... technically Java is also an interpreted language although >>>>> optimizations like Just In Time compilers tend to blur the distinction >>>>> somewhat. >>>> >>>> "Technically" Java is a compiled language. >>> >>> Ambiguous. >> >> Not at all. >> >> What is "javac"? > > Not a compiler as known outside of the Java world. It only creates > bytecode, not an executable file. Similar to: C# compiler that compiles C# code to MSIL byte code UCSD Pascal compiler that compiles Pascal code to p-code byte code Hip Hop compiler that compiles PHP to Hip Hop byte code Calling something that compiles to byte code is not a Java world thing - it is quite common - and have been used many years before Java was invented. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-24 22:34 -0400 |
| Message-ID | <mu2bsa$lgu$1@speranza.aioe.org> |
| In reply to | #32665 |
On 9/24/2015 9:58 PM, Arne Vajhøj wrote: > On 9/24/2015 7:55 PM, Jerry Stuckle wrote: >> On 9/24/2015 4:10 PM, Lew wrote: >>> On Thursday, September 24, 2015 at 2:40:16 AM UTC-7, Eternal Hope wrote: >>>> On 24/09/2015 00:10, Lew wrote: >>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope >>>>> wrote: >>>>>> ... technically Java is also an interpreted language although >>>>>> optimizations like Just In Time compilers tend to blur the >>>>>> distinction >>>>>> somewhat. >>>>> >>>>> "Technically" Java is a compiled language. >>>> >>>> Ambiguous. >>> >>> Not at all. >>> >>> What is "javac"? >> >> Not a compiler as known outside of the Java world. It only creates >> bytecode, not an executable file. > > Similar to: > > C# compiler that compiles C# code to MSIL byte code > UCSD Pascal compiler that compiles Pascal code to p-code byte code > Hip Hop compiler that compiles PHP to Hip Hop byte code > > Calling something that compiles to byte code is not a Java world > thing - it is quite common - and have been used many years > before Java was invented. Even if we take something very traditional like C and C++, then if we leave the application programmer view and go to the compiler internals view, then GCC (which is probably one of the most used compilers) really consists of: gcc/g++ compiler drivers cpp preprocessor cc1/cc1plus compiler as assembler collect2 linker [forgive me for the non-nix term] and guess what - the cc1/cc1plus compiler actually does not produce neither executable nor object code but instead assembly code. Arne
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web