Message-ID: <377A0DF8.1E1FAFE9@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 20 Date: Wed, 30 Jun 1999 16:30:51 GMT NNTP-Posting-Host: 198.232.144.27 X-Complaints-To: Abuse Role , We Care X-Trace: monger.newsread.com 930760251 198.232.144.27 (Wed, 30 Jun 1999 12:30:51 EDT) NNTP-Posting-Date: Wed, 30 Jun 1999 12:30:51 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newspeer1.nac.net!yellow.newsread.com!netaxs.com!newsread.com!POSTED.monger.newsread.com!not-for-mail jmfbahciv@aol.com wrote: > My point about people knowing that an assembly lanaguage exists is > so that those people have some idea of what is going on in the CPU. > There really are people who think that it's the ASCII that is getting > executed. Well, not ASCII, but weren't there some machines in the 1960's that directly executed high-level languages (Algol?) in source form (probably EBCDIC or maybe tokenized)? I believe there was also hardware developed that directly executed APL (of course in that case the programmer does the tokenization :-) ). There's the LISP Engine, but I don't know if it internally stored the code in human-readable or tokenized form. Of course, there's also Western Digital's chipset that directly executed UCSD P-code, but that's a little more than tokenization. Tim. ###### From: albaugh@agames.com (Mike Albaugh) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Followup-To: alt.folklore.computers,comp.arch Date: 30 Jun 1999 18:29:42 GMT Organization: Atari Games Corporation Lines: 55 Message-ID: <7ldnmm$ctu$1@null.agames.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: java.agames.com X-Trace: null.agames.com 930767382 13246 192.245.83.156 (30 Jun 1999 18:29:42 GMT) X-Complaints-To: abuse@agames.com NNTP-Posting-Date: 30 Jun 1999 18:29:42 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!nntp.abs.net!newshub2.home.com!news.home.com!newshub1-work.home.com!null!albaugh Tim Shoppa (shoppa@trailing-edge.com) wrote: : jmfbahciv@aol.com wrote: : > My point about people knowing that an assembly lanaguage exists is : > so that those people have some idea of what is going on in the CPU. : > There really are people who think that it's the ASCII that is getting : > executed. : Well, not ASCII, but weren't there some machines in the 1960's : that directly executed high-level languages (Algol?) in source : form (probably EBCDIC or maybe tokenized)? The closest that I recall to what you suggest was SYMBOL, an experimental computer funded by Fairchild (IIRC). It was "all hardware", including scheduler and "compiler", which massaged the user's character input into some sort of directly executable form. Similar, but slightly less ambitious, machines (mostly "paper", rather than silicon), are covered in Glenford Myers "Advances in Computer Architecture", a book that will probably seem surreal to today's comp.arch reader under a certain age :-) BTW: SYMBOL, or parts of it anyway, is at the Computer Museum History center, which can always use more support... (hint, hint :-) One could argue that the IBM 1401 and 1410 came close, if you count assmbly as a "High Level Language". These were BCD machines, although the 1401 "packed" the addresses, so that locations past 999 looked a little funny :-) But the interesting thing was that the opcodes themselves were mnemonic. Move was 'M', Add was 'A', Branch was 'B', etc. Even the non-alphabetic ones "made sense", e.g. Halt was '.' :-) Not very high-lvel, but seriously easy to whip out machine-code for... : I believe there was also hardware developed that directly executed : APL (of course in that case the programmer does the tokenization :-) ). Not the 5100, right? that one "knew" APL, but only because the interpreter was micro-coded. ANd I believe even it "tokenized" to some extent. One is not restricted to single-character variable names, after all, and there's a fair amount of baggage to a variable or function, so you'd at least want to use some sort of "unique token", possibly a pointer, instead of doing a string-search every time you encountered a variable name. : There's the LISP Engine, but I don't know if it internally stored : the code in human-readable or tokenized form. : Of course, there's also Western Digital's chipset that directly : executed UCSD P-code, but that's a little more than tokenization. Right. I'd love to hear of any such machines, but I haven't run across any, and I've run across some seriously wierd machines... Mike | albaugh@agames.com, speaking only for myself ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages ) Date: 30 Jun 1999 21:33:29 +0200 Organization: My own Private Self Lines: 42 Sender: neil@chonsp.franklin.ch Message-ID: <6ur9mtjxfa.fsf@chonsp.franklin.ch> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> X-Newsreader: Gnus v5.3/Emacs 19.34 Tim Shoppa writes: > > Well, not ASCII, but weren't there some machines in the 1960's > that directly executed high-level languages (Algol?) in source > form (probably EBCDIC or maybe tokenized)? I have head (as in heard from someone who head ...) of Fortran in hardware. This would have been very long ago, so most likely the simpler F66 and not F77. > There's the LISP Engine, but I don't know if it internally stored > the code in human-readable or tokenized form. Nope. It stores CONSes, i.e. pairs of pointers, one to data and the other to the next element. Sometimes lists of CONSes would for speed be drawn together as an an series of data pointers with only the occasional next pointer (where lists have been concatenated). The last next pointer allways being nil (null). Also actual data objects (numbers, symbols, strings, opcodes for the virtual machine) were intermingled. So pure binary. Although the Lisp nested brackets and symbols notation was an fairly exact image, it did need translating (by an simple recursive descent compiler) into pointer-and-objects binary. Forth also works at the same level of symbol->binary compilation with runtime hangling through the nested lists. > Of course, there's also Western Digital's chipset that directly > executed UCSD P-code, but that's a little more than tokenization. Actually p-code seems to have been fairly similar to Java (or m-lisp) bytecode. -- Neil Franklin, Nerd, Geek, Unix Wizzard and Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Computer: toy that speeds work, so you have more time to play with it ###### From: euphrates@freenet.co.uk Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 1 Jul 1999 22:45:57 GMT Organization: Cable Internet (post doesn't reflect views of Cable Internet) Lines: 16 Message-ID: <7lgr35$83a$3@news1.cableinet.co.uk> References: <377e670a.12577535@news.demon.co.uk> NNTP-Posting-Host: 212.1.149.242 X-Trace: news1.cableinet.co.uk 930869157 8298 212.1.149.242 (1 Jul 1999 22:45:57 GMT) X-Complaints-To: abuse@cableinet.net NNTP-Posting-Date: 1 Jul 1999 22:45:57 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newspeer1.nac.net!easynet-tele!easynet.net!news5.cableinet.net!cableinet-uk!news1.cableinet.co.uk!not-for-mail On 1999-07-01 brian@shapes.demon.co.uk(BrianDrummond) said: :LINGO lives on, though only as a curiosity (as far as I know ...?) :I still have a 16-bit DOS implementation that never quite got :finished - apart from persistent storage and windows, it's complete :(including GC) and runs just fine - a bit faster, on my 200MHz :Pentium, than on the 6MHz (microcode, about 2M Lingo :instructions/second) Rekursiv. :It's still the easiest tool I have for solving a few problems. Oooh... is it freely available? -- Communa -- you know soft spoken changes nothing ###### From: Lee Courtney Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Wed, 30 Jun 1999 12:22:00 -0700 Organization: Monterey Software Group Inc. Lines: 26 Message-ID: <377A6E58.2A3C5134@slip.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: 209.152.187.223 NNTP-Posting-Date: Wed, 30 Jun 1999 19:27:30 GMT X-Trace: 930770850.679.46 S0YUSD2PSBBDFD198C qube-01.us-ca.remarq.com X-Complaints-To: newsabuse@remarQ.com X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!remarQ73!supernews.com!remarQ.com!remarQ69!corp.remarQ.com!not-for-mail Tim Shoppa wrote: > > Well, not ASCII, but weren't there some machines in the 1960's > that directly executed high-level languages (Algol?) in source > form (probably EBCDIC or maybe tokenized)? > > I believe there was also hardware developed that directly executed > APL (of course in that case the programmer does the tokenization :-) ). Micro Computing Machines aka MCM was a 1975ish luggable that implemented a microcoded APL interpreter. Swapping device was single or dual cassette tape drives! Regards, Lee Courtney President -- Monterey Software Group Inc. Voice: 650-964-7052 1350 Pear Avenue, Suite J Fax: 650-964-6735 Mountain View, California 94043-1302 Pager: 408-237-1705 Email: leec AT-SIGN slip DOT net http://www.editcorp.com/Businesses/MontereySoftware Mainframe Network, Session, and Batch Authentication, Audit, and Access Control for Hewlett-Packard 3000 Business Servers ###### From: Lee Courtney Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Wed, 30 Jun 1999 12:23:06 -0700 Organization: Monterey Software Group Inc. Lines: 26 Message-ID: <377A6E9A.2F95C368@slip.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: 209.152.187.223 NNTP-Posting-Date: Wed, 30 Jun 1999 19:28:35 GMT X-Trace: 930770915.024.48 S0YUSD2PSBBDFD198C qube-01.us-ca.remarq.com X-Complaints-To: newsabuse@remarQ.com X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news0.de.colt.net!colt.net!newspeer.clara.net!news.clara.net!remarQ-uK!remarQ73!supernews.com!remarQ.com!remarQ69!corp.remarQ.com!not-for-mail Tim Shoppa wrote: > > Well, not ASCII, but weren't there some machines in the 1960's > that directly executed high-level languages (Algol?) in source > form (probably EBCDIC or maybe tokenized)? > > I believe there was also hardware developed that directly executed > APL (of course in that case the programmer does the tokenization :-) ). Micro Computing Machines aka MCM was a 1975ish luggable that implemented a microcoded APL interpreter. Swapping device was single or dual cassette tape drives! Regards, Lee Courtney President -- Monterey Software Group Inc. Voice: 650-964-7052 1350 Pear Avenue, Suite J Fax: 650-964-6735 Mountain View, California 94043-1302 Pager: 408-237-1705 Email: leec AT-SIGN slip DOT net http://www.editcorp.com/Businesses/MontereySoftware Mainframe Network, Session, and Batch Authentication, Audit, and Access Control for Hewlett-Packard 3000 Business Servers ###### From: Lee Courtney Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Wed, 30 Jun 1999 12:36:17 -0700 Organization: Monterey Software Group Inc. Lines: 51 Message-ID: <377A71B1.DC8E49B0@slip.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7ldnmm$ctu$1@null.agames.com> NNTP-Posting-Host: 209.152.187.223 NNTP-Posting-Date: Wed, 30 Jun 1999 19:41:48 GMT X-Trace: 930771708.222.85 S0YUSD2PSBBDFD198C qube-01.us-ca.remarq.com X-Complaints-To: newsabuse@remarQ.com X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!remarQ-easT!remarQ73!supernews.com!remarQ.com!remarQ69!corp.remarQ.com!not-for-mail Mike Albaugh wrote: (snipped for brevity) > BTW: SYMBOL, or parts of it anyway, is at the Computer Museum > History center, which can always use more support... (hint, > hint :-) Agreed! (http://www.computerhistory.org) > : I believe there was also hardware developed that directly executed > : APL (of course in that case the programmer does the tokenization :-) ). > > Not the 5100, right? that one "knew" APL, but only because > the interpreter was micro-coded. ANd I believe even it "tokenized" > to some extent. One is not restricted to single-character variable > names, after all, and there's a fair amount of baggage to a variable > or function, so you'd at least want to use some sort of "unique token", > possibly a pointer, instead of doing a string-search every time you > encountered a variable name. Was APL actually microcoded on the 5100? I was under the impression that the 5100 implemented a 360 instruction set and just ran APL\360. Yes? No? > : Of course, there's also Western Digital's chipset that directly > : executed UCSD P-code, but that's a little more than tokenization. > > Right. I'd love to hear of any such machines, but I haven't > run across any, and I've run across some seriously wierd machines... One's sitting in the workshop area of the The Computer Museum History Center (TCMHC) right now - a 21MX Hewlett-Packard donated a couple months ago. Dave Babcock of SGI (and volunteer at TCMHC) microcoded a P-code interpreter on the 21MX when he was at UCLA(?). His implementation made some interesting and efficient uses of the 21MX micromachine. Regards, Lee Courtney President -- Monterey Software Group Inc. Voice: 650-964-7052 1350 Pear Avenue, Suite J Fax: 650-964-6735 Mountain View, California 94043-1302 Pager: 408-237-1705 Email: leec AT-SIGN slip DOT net http://www.editcorp.com/Businesses/MontereySoftware Mainframe Network, Session, and Batch Authentication, Audit, and Access Control for Hewlett-Packard 3000 Business Servers ###### From: abaum@pa.dec.com (Allen J. Baum) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Wed, 30 Jun 1999 17:01:38 -0700 Organization: Compaq Computer Lines: 28 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: althea.pa.dec.com X-Newsreader: MT-NewsWatcher 2.4.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.berkeley.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!news1.digital.com!pa.dec.com!src.dec.com!abaum In article <377A0DF8.1E1FAFE9@trailing-edge.com>, Tim Shoppa wrote: > jmfbahciv@aol.com wrote: > > My point about people knowing that an assembly lanaguage exists is > > so that those people have some idea of what is going on in the CPU. > > There really are people who think that it's the ASCII that is getting > > executed. > > Well, not ASCII, but weren't there some machines in the 1960's > that directly executed high-level languages (Algol?) in source > form (probably EBCDIC or maybe tokenized)? > > I believe there was also hardware developed that directly executed > APL (of course in that case the programmer does the tokenization :-) ). > > There's the LISP Engine, but I don't know if it internally stored > the code in human-readable or tokenized form. > > Of course, there's also Western Digital's chipset that directly > executed UCSD P-code, but that's a little more than tokenization. > > Tim. And then there is the Fairchild Symbol machine. Decimal floating point in hardware. OS in hardware 'Compiler' in hardware. ..... ###### From: TheCentralScrutinizer.147@pobox.com () Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 30 Jun 1999 20:04:28 GMT Organization: http://extra.newsguy.com Lines: 9 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> Reply-To: TheCentralScrutinizer.147@pobox.com NNTP-Posting-Host: edison.chisp.net X-Newsreader: slrn (0.9.3.2 UNIX) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!logbridge.uoregon.edu!pln-w!spln!extra.newsguy.com!newsp.newsguy.com!TheCentralScrutinizer.147 I believe the intel 432 was supposed to run ada. I've also heard of a microprocessor that directly executed forth and another that executed P-code. If you don't want to be to technical about it, the basic-stamp single chip computers directly execute BASIC although it is via a ROM and an F8 (?) microprocessor instead of microcode. ###### From: albaugh@agames.com (Mike Albaugh) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Followup-To: alt.folklore.computers,comp.arch Date: 30 Jun 1999 21:41:47 GMT Organization: Atari Games Corporation Lines: 51 Message-ID: <7le2ur$mp1$1@null.agames.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> NNTP-Posting-Host: java.agames.com X-Trace: null.agames.com 930778907 23329 192.245.83.156 (30 Jun 1999 21:41:47 GMT) X-Complaints-To: abuse@agames.com NNTP-Posting-Date: 30 Jun 1999 21:41:47 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!nntp.abs.net!newshub2.home.com!newshub1.home.com!news.home.com!newshub1-work.home.com!null!albaugh TheCentralScrutinizer.147@pobox.com wrote: : I believe the intel 432 was supposed to run ada. Well, in a sense, but only in roughly the same sense that the Burroughs 6000 series (Now Unisys A-series) "execute Algol". The instruction-set was designed to be an "good target" for Ada, but it no more "executed Ada" than a 386 "executes C" (Note that a lot of the appeal of Ada lies in the strict semantics that nonetheless allow "hoisting" such things as bounds-checks at compile time. I'm trying to imagine hardware being _so_ much faster that it could lose that advantage and still come out ahead, on vanilla code) : I've also heard of a microprocessor that directly executed forth and : another that executed P-code. The P-Code machine was a Western-Digital re-microcoding of the LSI-11 chipset, but again, P-Code is not Pascal. Neither do any of the "Forth machines" of which I am aware "directly execute" Forth, in the sense that the original posting in this thread implied (re-reading the human-readble text every time). Scripting languages and some _really_ primitive BASIC's do, but not typically in hardware. : If you don't want to be to technical about it, the basic-stamp single chip : computers directly execute BASIC although it is via a ROM and an F8 (?) : microprocessor instead of microcode. PIC, actually. Does the stamp just re-parse every line every time (ala Tiny Basic), or does it tokenise on entry, as most BASICs do? There have been a number of "single language" machines built. Usually the language was implemented in software on the actual "bare machine". Another set of machines used micro-code to implement a "nicer" virtual-machine (e.g. P-Code, or JVM). SYMBOL even skipped the micro-code part, but I'm still waiting to hear about a machine that: 1) Had an internal form of the program that was not "pre-disgested" (threaded code, tokens, LISP cells, ...) 2) Traversed that internal form purely in hardware, or even microcode. We have a few examples of (1), and a few of (2), but none (so far) of both at the same time... BTW: yes, I forgot whether the 5100 was one or two "layers" in its APL interpreter. I'm pretty sure that in any case, it did at least tokenise the user's input. Mike | albaugh@agames.com, speaking only for myself ###### From: Tim Bradshaw Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 01 Jul 1999 00:49:43 +0100 Organization: TFEB.ORG Ltd Sender: tfb@lostwithiel.tfeb.org Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: tfeb.demon.co.uk X-NNTP-Posting-Host: tfeb.demon.co.uk:212.229.44.190 X-Trace: news.demon.co.uk 930807428 nnrp-10:27148 NO-IDENT tfeb.demon.co.uk:212.229.44.190 X-Complaints-To: abuse@demon.net X-Newsreader: Gnus v5.2.25/XEmacs 19.14 Lines: 19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!news0.de.colt.net!colt.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!tfeb.demon.co.uk!lostwithiel!nobody * Tim Shoppa wrote: > There's the LISP Engine, but I don't know if it internally stored > the code in human-readable or tokenized form. I'm not familiar with the instruction set of the very early lisp machines (the CONS & CADR machine from MIT), but the Symbolics 3600 (the successor machine to the CADR, which Symbolics first commericalised) and successors executed a fairly conventional, if lisp-oriented, instruction set. They were stack machines (easy to compile for I guess) with hardware typechecking, GC support, but they didn't in any sense execute Lisp directly -- there was a compiler, which in some ways was quite sophisticated. Later Lisp machines had instruction sets even further from the Lisp level, to the extent that the LMI K machine (of which no complete examples were made I think) was described as basically a RISC machine, but with typechecking going on in parallel to the main thread of execution. --tim ###### From: samiam@cisco.com (Scott A. spam-me-some-moore) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 01:32:59 GMT Organization: Cisco.com Lines: 47 Message-ID: <7leggb$r8g$1@news-sj-3.cisco.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: dhcp-n-45-202.cisco.com Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII X-Newsreader: WinVN 0.99.9 (Released Version) (x86 32bit) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!logbridge.uoregon.edu!nuq-peer.news.verio.net!uunet!lax.uu.net!ffx.uu.net!in5.uu.net!news-master.cisco.com!not-for-mail In article <377A0DF8.1E1FAFE9@trailing-edge.com>, shoppa@trailing-edge.com says... > >jmfbahciv@aol.com wrote: >> My point about people knowing that an assembly lanaguage exists is >> so that those people have some idea of what is going on in the CPU. >> There really are people who think that it's the ASCII that is getting >> executed. > >Well, not ASCII, but weren't there some machines in the 1960's >that directly executed high-level languages (Algol?) in source >form (probably EBCDIC or maybe tokenized)? > >I believe there was also hardware developed that directly executed >APL (of course in that case the programmer does the tokenization :-) ). > >There's the LISP Engine, but I don't know if it internally stored >the code in human-readable or tokenized form. > >Of course, there's also Western Digital's chipset that directly >executed UCSD P-code, but that's a little more than tokenization. > >Tim. Don't shoot me, but at the time of the Western Digital P-Machine (which by the way was a PDP-11 chipset with different microcode) there was a small article in a magazine stating that the benchmarks for the chip were not spectacular compared to a standard machine of the time (like 68000) running code compiled conventionally. It brings to mind the proverb: "The first thing you learn from history is that no one learns from history".... The Java machine (hardware chip to execute bytecode) project is now twisting in the wind, with most of the fabs who initally stating support putting off actual silicon indefinately. When I entered programming, one of the leading designers of the day stated that we would be building "more machines within machines" with reference to the 8086 being based on Microcode vs the old random logic method. Even Intel has realized that this is heading downtown against traffic. The rule now is that real execution at hardware is a platform that is going down, down, to lower and lower levels of execution, with software bridging the gap. [sam] ###### Message-ID: <377AA378.72CC66A9@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 39 Date: Thu, 01 Jul 1999 03:07:48 GMT NNTP-Posting-Host: 198.232.144.27 X-Complaints-To: Abuse Role , We Care X-Trace: newshog.newsread.com 930798468 198.232.144.27 (Wed, 30 Jun 1999 23:07:48 EDT) NNTP-Posting-Date: Wed, 30 Jun 1999 23:07:48 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!netnews.com!newspeer1.nac.net!yellow.newsread.com!netaxs.com!newsread.com!POSTED.newshog.newsread.com!not-for-mail Scott A. spam-me-some-moore wrote: > Don't shoot me, but at the time of the Western Digital P-Machine > (which by the way was a PDP-11 chipset with different microcode) > there was a small article in a magazine stating that the benchmarks > for the chip were not spectacular compared to a standard machine > of the time (like 68000) running code compiled conventionally. The "time" of the Western Digital chipset that made the PDP-11/03 and the P-Engine was mid-1970's. Certainly they weren't hot performers compared to later micros like 68000's, but they did compare nicely against the contemporaneous micros (8080A, 6800, F8, 1802, etc.) It was extremely common at the time on minicomputers to compile source code into "threaded code", minimizing memory requirements in exchange for slightly longer execution time. Many mini's of the mid-70's were already hitting up their address space limitations and compact code was a prime concern. > It brings to mind the proverb: "The first thing you learn from history > is that no one learns from history".... The Java machine (hardware > chip to execute bytecode) project is now twisting in the wind, with > most of the fabs who initally stating support putting off actual > silicon indefinately. > > When I entered programming, one of the leading designers of the > day stated that we would be building "more machines within machines" > with reference to the 8086 being based on Microcode vs the old > random logic method. > > Even Intel has realized that this is heading downtown against > traffic. The rule now is that real execution at hardware is a platform > that is going down, down, to lower and lower levels of execution, > with software bridging the gap. This isn't so obvious these days. After all, isn't instruction stream bandwidth an important consideration? If so, history may see us swinging towards CISCier instruction sets yet again. Tim. ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 04:44:17 GMT Organization: Netcom Lines: 16 Message-ID: <7lern1$987@dfw-ixnews6.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Wed Jun 30 11:44:17 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!ix.netcom.com!not-for-mail In comp.arch Tim Shoppa wrote: : This isn't so obvious these days. After all, isn't instruction : stream bandwidth an important consideration? If so, history may : see us swinging towards CISCier instruction sets yet again. No. At least not for the high performance end of the spectrum. Look at IA64 for the latest example of march down the path of decreased code density. The position above is the one taken by Wirth in his mid to late 80's CACM paper on computer architecture. Using code density as a direct figure of merit is just plain wrong if performance, or even cost on general purpose systems, is what you're trying to optimize. -Z- ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 05:52:47 GMT Organization: Daedalus Consulting Lines: 19 Message-ID: <930808365.758513@estelle.paradise.net.nz> References: <7lassu$p2q$1@mail.pl.unisys.com> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> NNTP-Posting-Host: estelle.paradise.net.nz X-Trace: titan.xtra.co.nz 930808367 4589778 203.96.152.5 (1 Jul 1999 05:52:47 GMT) X-Complaints-To: abuse@xtra.co.nz NNTP-Posting-Date: 1 Jul 1999 05:52:47 GMT Cache-Post-Path: estelle.paradise.net.nz!unknown@p16-cable.paradise.net.nz X-Cache: nntpcache 2.3.3b4 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!lsanca1-snf1!news.gtei.net!news.netgate.net.nz!news.xtra.co.nz!don In article <7leggb$r8g$1@news-sj-3.cisco.com>, Scott A. spam-me-some-moore wrote: >Don't shoot me, but at the time of the Western Digital P-Machine >(which by the way was a PDP-11 chipset with different microcode) >there was a small article in a magazine stating that the benchmarks >for the chip were not spectacular compared to a standard machine >of the time (like 68000) running code compiled conventionally. IIRC, that was the LSI-11 chipset. The LSI-11 was sluggish running the pdp11 microcode too. I'd be surprised if the "p-code shipset" was slower than an LSI-11 running a p-code interpreter written in pdp11 code, but not at all surprised to find it running slower than p-code on contemporary processors. Note that the LSI-11 came out circa 1975, I imagine the p-code chip came later? The 68000 was around '78. Even a 6502 or 6809 could give an LSI-11 a pretty good run for its money. -- don ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 06:22:39 GMT Organization: Netcom Lines: 17 Message-ID: <7lf1ff$5c8@dfw-ixnews4.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lern1$987@dfw-ixnews6.ix.netcom.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Thu Jul 01 1:22:39 AM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newscore.gigabell.net!newscore.ipf.de!isdnet!netnews.com!newshub.northeast.verio.net!ix.netcom.com!not-for-mail In comp.arch Zalman Stern wrote: : The position above is the one taken by Wirth in his mid to late 80's CACM : paper on computer architecture. To clarify, this last sentence is about Tim's claim that instruction bandwidth concerns argue for a CISCier instruction set. Wirth's paper defended a number of CISC architectures, notably the NS32032 family, against the onslaught of RISC architectures with data that showed they delivered superior code density. Yet these architectures continued to fall behind in performance. (Some will point out that CISC is still dominant marketwise. IIRC, the 386 was behind Lilith, the NS32032, and the 68k in terms of code density. x86 code density has also likely decreased slightly over the last decade due to favoring simpler instruction sequences.) -Z- ###### From: Harvey Taylor Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 01 Jul 1999 07:11:38 -0700 Organization: Organization? What organization?! Lines: 26 Message-ID: <377B771A.7A45@despam.pangea.ca> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lern1$987@dfw-ixnews6.ix.netcom.com> NNTP-Posting-Host: dock07-00-14.ner.pangea.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: pumpkin.pangea.ca 930831155 28030 207.161.114.78 (1 Jul 1999 12:12:35 GMT) X-Complaints-To: abuse@pangea.ca NNTP-Posting-Date: 1 Jul 1999 12:12:35 GMT X-Mailer: Mozilla 2.02 (Win16; I) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!sunqbc.risq.qc.ca!cyclone.mbnet.mb.ca!pumpkin.pangea.ca!news.pangea.ca!not-for-mail Zalman Stern wrote: > In comp.arch Tim Shoppa wrote: > : This isn't so obvious these days. After all, isn't instruction > : stream bandwidth an important consideration? If so, history may > : see us swinging towards CISCier instruction sets yet again. > > No. At least not for the high performance end of the spectrum. Look at IA64 > for the latest example of march down the path of decreased code density. > > The position above is the one taken by Wirth in his mid to late 80's CACM > paper on computer architecture. Using code density as a direct figure of > merit is just plain wrong if performance, or even cost on general purpose > systems, is what you're trying to optimize. > You are talking about what is happening in one computer. I wonder if this is also true in the 'network computer' case where computer B is executing/interpreting a byte stream received from computer A? -het -- "Simplicity is the ultimate sophistication." - old Apple logo Harvey Taylor het@despam.pangea.ca ###### From: Chris Morgan Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 01 Jul 1999 07:41:12 -0400 Organization: Linux Hackers Unlimited Lines: 33 Sender: cm@mihalis.ix.netcom.com Message-ID: <87r9ms4mxz.fsf@mihalis.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: a5.f7.29.7e X-Server-Date: 1 Jul 1999 11:41:12 GMT X-Newsreader: Gnus v5.5/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!netnews.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!not-for-mail Tim Shoppa writes: > jmfbahciv@aol.com wrote: > > My point about people knowing that an assembly lanaguage exists is > > so that those people have some idea of what is going on in the CPU. > > There really are people who think that it's the ASCII that is getting > > executed. > > Well, not ASCII, but weren't there some machines in the 1960's > that directly executed high-level languages (Algol?) in source > form (probably EBCDIC or maybe tokenized)? > > I believe there was also hardware developed that directly executed > APL (of course in that case the programmer does the tokenization :-) ). > > There's the LISP Engine, but I don't know if it internally stored > the code in human-readable or tokenized form. > > Of course, there's also Western Digital's chipset that directly > executed UCSD P-code, but that's a little more than tokenization. Just after I got my head around how multi-threaded programs are executed on a single normal CPU, I read about a cpu that had all the Ada tasking primitives implemented in hardware. Perhaps that kind of thing will come again for Java. Chris -- Chris Morgan References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: cobalt.transmeta.com X-Newsreader: Gnus v5.3/Emacs 19.34 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!news2.best.com!news1.best.com!news.transmeta.com!not-for-mail Tim Bradshaw writes: > > * Tim Shoppa wrote: > > > There's the LISP Engine, but I don't know if it internally stored > > the code in human-readable or tokenized form. > > I'm not familiar with the instruction set of the very early lisp > machines (the CONS & CADR machine from MIT), but the Symbolics 3600 > (the successor machine to the CADR, which Symbolics first > commericalised) and successors executed a fairly conventional, if > lisp-oriented, instruction set. They were stack machines (easy to > compile for I guess) with hardware typechecking, GC support, but they > didn't in any sense execute Lisp directly -- there was a compiler, > which in some ways was quite sophisticated. Later Lisp machines had > instruction sets even further from the Lisp level, to the extent that > the LMI K machine (of which no complete examples were made I think) > was described as basically a RISC machine, but with typechecking going > on in parallel to the main thread of execution. If I'm not mistaken the CONS and CADRs also were somewhat conventional stack machines, although with similar Lisp support. The Scheme-79 and Scheme-81 chips executed a tree-structured parse tree for Scheme (S-Code) directly in hardware. To the programmer, there was nothing but S-Code (registers, stack, or otherwise). Support for Lispy types (lists, etc.) was very good, but (if memory serves) there was minimal support for numeric types -- a numeric co-processor was envisioned but never designed. To support first class continuations, the Scheme-81 chip did not even emulate a stack at all -- control state was maintained in heap-allocated linked lists. I don't know whether this feature was shared by the Scheme-79 chip. ###### From: Terje Mathisen Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 01 Jul 1999 08:44:34 +0200 Organization: Hydro Lines: 48 Message-ID: <377B0E52.E5676371@hda.hydro.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> NNTP-Posting-Host: 136.164.10.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.06 [en] (WinNT; I) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!newsfeed.tli.de!news.algonet.se!algonet!newsfeed1.online.no!newsfeed.online.no!hydro.com!not-for-mail TheCentralScrutinizer.147@pobox.com wrote: > > I believe the intel 432 was supposed to run ada. > > I've also heard of a microprocessor that directly executed forth and > another that executed P-code. > > If you don't want to be to technical about it, the basic-stamp single chip > computers directly execute BASIC although it is via a ROM and an F8 (?) > microprocessor instead of microcode. This was the standard approach for HP's lab micros (models 85/87) (around 1980+), they had a 'HP-Basic' operating system with no capability to run anything else. You had to live within the Basic environment all the time, the only way to break out of it was to buy the asm kit and then extend the Basic language with whatever functionality you needed. I.e. Basic was still the master. In some ways this was equivalent to loadable microcode, with equal or better chances of messing up the machine in some interesting way. Terje PS. To make a Basic extension, you had to write the code three different ways: 1) The parser/tokenizer to handle the new keyword(s) and any parameter(s) 2) The actual runtime code. This could be fun in an 8-bit micro with 64 (?) registers, where instructions could either work on a single byte, or on all the bytes up to the next 'hard stop'. The 'hard stop's divided those 64 regs into one block of 16-bit regs and another of 64-bit regs which was used for BCD-encoded fp. 3) The lister or de-tokenizer. The language/operating system used incremental compiling (tokenization), so each time you hit Enter while positioned on a source code line, it would be parsed immediately, and (in case of an error) the cursor moved back to the offending position. -- - Using self-discipline, see http://www.eiffel.com/discipline "almost all programming can be viewed as an exercise in caching" ###### From: torbenm@diku.dk (Torben AEgidius Mogensen) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 10:39:39 +0200 Organization: Department of Computer Science, U of Copenhagen Lines: 14 Message-ID: <7lf9gb$isg@grimer.diku.dk> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: grimer.diku.dk X-Trace: vidar.diku.dk 930818379 4684 130.225.96.251 (1 Jul 1999 08:39:39 GMT) X-Complaints-To: news@diku.dk NNTP-Posting-Date: 1 Jul 1999 08:39:39 GMT X-Newsreader: NN version 6.5.1 #3 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!uninett.no!news.net.uni-c.dk!vidar!grimer.diku.dk!not-for-mail The "Perq" workstation from Three Rivers used a microprogrammable chip which was microcoded to run P-code. The Rekursiv processor was designed to run a language called LINGO. Neither of these can, however, be said to execute the HLL directly, but they do execute a form that is close to the HLL. One can, however, wonder if there is much difference between a CPU that is microcoded to run a HLL and a RISC CPU that runs an interpreter for a HLL, especially if the interpreter is stored in ROM. Torben Mogensen (torbenm@diku.dk) ###### From: jthorn@davinci.thp.univie.ac.at (Jonathan Thornburg) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 12:01:54 +0200 Organization: Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik Lines: 124 Message-ID: <7lfeai$430$1@davinci.thp.univie.ac.at> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: davinci.thp.univie.ac.at X-Trace: www.univie.ac.at 930823318 123888 131.130.87.94 (1 Jul 1999 10:01:58 GMT) X-Complaints-To: news-adm@news.univie.ac.at NNTP-Posting-Date: 1 Jul 1999 10:01:58 GMT Summary: description of a early-1980s prototype APL machine Keywords: APL, microcode, interpreter Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newscore.univie.ac.at!newsfeed03.univie.ac.at!news.univie.ac.at!not-for-mail In article <377A0DF8.1E1FAFE9@trailing-edge.com>, Tim Shoppa asked >weren't there some machines in the 1960's >that directly executed high-level languages (Algol?) in source >form (probably EBCDIC or maybe tokenized)? > >I believe there was also hardware developed that directly executed >APL (of course in that case the programmer does the tokenization :-) ). As an undergraduate I worked on Richard Hobson's "SAM" (Structured Architecture Machine) project in the Simon Fraser University (Vancouver, BC, Canada) CS dept, around 1980-81. This was a true APL machine, in the same manner as the Symbolics machines were true Lisp machines. At the time I worked on it, SAM was built around dual (Micron?) MK-16 16-bit microprocessors, programmed in vertical microcode. (You could look on the MK-16 as a crude RISC machine, but it's probably more accurate to think of it as a 16-bit bit-slice chip. As I recall, microinstructions were around 30 bits long.) The basic design looked like this: [[Note to the non-APL-cognoscenti: in APL, *all* data objects are arrays. "Scalars" are just the special case of 0-dimensional array.]] +-------------+ | IO | PMU = Program Management Unit | processor | (APL interpreter) | (Z-80) | | (assembler) | DMU = Data Management Unit +-------------+ (all array operations) /|\ | | \|/ +-------------+ --------+ +-------------+ | | -------->::::|-----> | | | PMU | --------+ | DMU | | (MK-16) | | (MK-16) | | (microcode) | +-------- | (microcode) | | | <-----|::::<-------- | | +-------------+ +-------- +-------------+ /|\ /|\ | | | | \|/ \|/ +-------------+ +-------------+ | symbol | | symbol | | table | | table | | | | | | APL fns | | APL arrays | | | | | +-------------+ +-------------+ The PMU handled the main logic for the APL interpreter. This was all written in MK-16 microcode. (Part of) the symbol table was stored in the PMU's off-chip (segmented virtual) memory. User APL functions were also stored there. (Except for temporary editing buffers, this was the *only* in-memory storage for user APL functions; the APL-source-text to internal-form "assembly" transformation was reversible to recover the source for display, editing, or other external IO. I never did figure out why we didn't just keep the source on disk, as that would have allowed some streamlining of the PMU's internal representation, not to mention allowing comment text not to tie up PMU memory.) The internal form of user APL functions was sort of a hybrid of RPN and 3-operand assembler-type operations, with "APL array" being the basic data object. The PMU interpreted this, and sent low-level data manipulation instructions (referring to APL arrays by an integer symbol table index) to the DMU via a queue. The DMU maintained a parallel symbol table in its off-chip (segemented virtual) memory, so it could understand symbol table indices coming >from the PMU. The DMU did all the actual manipulation of APL arrays, again programmed entirely in MK-16 microcode. There was no hardware assist for big-array operations. Indeed, the MK-16 hardware provided (only) 16-bit integer arithmetic, so bigger integers and all floating point had to be done in (microcoded) software. For conditional branches and the APL execute function (which takes a user-level APL string and executes it as APL source code), the PMU sent the DMU instructions on what to do, and the DMU sent status codes back to the PMU via another queue. The whole architecture was designed, and the internal representations were optimized, to keep interpretive overheads low and make common cases (scalars and small arrays) run fast. As I recall, the function-call overhead was well under a dozen cycles, and the fast-path scalar integer I <- I+1 was 2 or 3 cycles. For Fortran-like loops, our fast-path code was basically as fast as anything a Fortran compiler could have generated, subject to the constraint that we treated each APL primitive independently. Another interesting aspect to this project was that all the microcode was initially written and debugged in APL itself, using cover functions simulating the machine's operation. APL is in fact quite a nice for this kind of thing, similarly to how LISP is a nice environment for building new AI languages. Alas, with tight funding and at most 3-4 people working on the project, it took quite a few years to get a working system, and by that time the state of the art in hardware had moved a long ways past the MK-16. When I worked on the project the hardware wasn't ready yet. However, I wrote enough of the architecture simulator and enough of the PMU's APL-interpreter microcode so I could run Ackermann's function (hand- compiled). When I left SFU in 1983 I believe Dr. Hobson had a wire-wrapped prototype working, but I don't think it was ever even close to being ready for commercial product production engineering. A project like this really needs at least an order of magnitude more resources than we had. -- -- Jonathan Thornburg http://www.thp.univie.ac.at/~jthorn/home.html Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik "The first strike in the American Colonies was in 1776 in Philadelphia, when [...] carpenters demanded a 72-hour week." -- Anatole Beck ###### From: "Andy Glew" Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 1 Jul 1999 12:04:02 -0500 Organization: University of Wisconsin, Madison Lines: 17 Message-ID: <7lg719$qr4$1@news.doit.wisc.edu> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lern1$987@dfw-ixnews6.ix.netcom.com> <377B771A.7A45@despam.pangea.ca> NNTP-Posting-Host: ras-c5800-3-50-246.dialup.wisc.edu X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!newsfeed.cwix.com!208.155.48.9!news.binc.net!nntp.chorus.net!news.itis.com!news.doit.wisc.edu!not-for-mail > You are talking about what is happening in one computer. > I wonder if this is also true in the 'network computer' case > where computer B is executing/interpreting a byte stream > received from computer A? The biggest factor in minimizing code size for transmission over a network is not instruction encoding, but is the provision of standard libraries that can be relied on being present, and that need not be transmitted. And/or a facility for caching these libraries. I.e. it is not Java that matters. It is the Java class libraries. ###### From: brian@shapes.demon.co.uk (Brian Drummond) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 01 Jul 1999 13:05:45 GMT Message-ID: <377e670a.12577535@news.demon.co.uk> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7lf9gb$isg@grimer.diku.dk> NNTP-Posting-Host: shapes.demon.co.uk X-NNTP-Posting-Host: shapes.demon.co.uk:158.152.228.158 X-Trace: news.demon.co.uk 930834097 nnrp-09:15438 NO-IDENT shapes.demon.co.uk:158.152.228.158 X-Complaints-To: abuse@demon.net X-Newsreader: Forte Agent 1.5/32.452 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 42 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!dispose.news.demon.net!demon!news.demon.co.uk!demon!shapes.demon.co.uk!not-for-mail On 1 Jul 1999 10:39:39 +0200, torbenm@diku.dk (Torben AEgidius Mogensen) wrote: > >The "Perq" workstation from Three Rivers used a microprogrammable chip >which was microcoded to run P-code. > >The Rekursiv processor was designed to run a language called LINGO. > >Neither of these can, however, be said to execute the HLL directly, >but they do execute a form that is close to the HLL. > LINGO lives on, though only as a curiosity (as far as I know ...?) I still have a 16-bit DOS implementation that never quite got finished - apart from persistent storage and windows, it's complete (including GC) and runs just fine - a bit faster, on my 200MHz Pentium, than on the 6MHz (microcode, about 2M Lingo instructions/second) Rekursiv. It's still the easiest tool I have for solving a few problems. Of course, the name LINGO has more recently been rebound to a multimedia scripting language :( >One can, however, wonder if there is much difference between a CPU >that is microcoded to run a HLL and a RISC CPU that runs an >interpreter for a HLL, especially if the interpreter is stored in ROM. Or if the microcode is stored in RAM - say, as close to the CPU as I-cache... If you had cache hints - e.g. fairly explicit "don't trash these cache lines x,y,z " instructions, coupled to some form of shorthand, i.e. "this word expands to cache line x you preserved earlier" then I would suggest there is no difference whatsoever. (It follows that adding such instructions to a RISC or VLIW would allow it to bridge the semantic gap, and thus run as slow as treacle. Proof is left as an exercise to the reader ;) - Brian ###### From: glmar04@swirl.mcc.ac.uk (Geoff Lane) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 14:26:21 GMT Organization: Manchester Computing Lines: 8 Message-ID: <7lftqd$bbm$1@yama.mcc.ac.uk> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> NNTP-Posting-Host: swirl.mcc.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.1 X-Face: 5d`B697Bi6BD>=hLUzS-!. Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.icl.net!ayres.ftech.net!news.ftech.net!newspeer.clara.net!news.clara.net!peernews!peer.news.bb.u-net.net!u-net!yama.mcc.ac.uk!not-for-mail Once saw a paper describing a h/w system that ran Fortran. Might have been in CACM 25 odd years ago. -- Geoff. Lane. Manchester Computing If the shoe fits, put it in your mouth. ###### From: albaugh@agames.com (Mike Albaugh) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Followup-To: alt.folklore.computers,comp.arch Date: 1 Jul 1999 15:52:01 GMT Organization: Atari Games Corporation Lines: 53 Message-ID: <7lg2r1$o22$1@null.agames.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <377AA378.72CC66A9@trailing-edge.com> <7lern1$987@dfw-ixnews6.ix.netcom.com> <7lf1ff$5c8@dfw-ixnews4.ix.netcom.com> NNTP-Posting-Host: java.agames.com X-Trace: null.agames.com 930844321 24642 192.245.83.156 (1 Jul 1999 15:52:01 GMT) X-Complaints-To: abuse@agames.com NNTP-Posting-Date: 1 Jul 1999 15:52:01 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.abs.net!newshub2.home.com!news.home.com!newshub1-work.home.com!null!albaugh Zalman Stern (zalman@netcom15.netcom.com) wrote: : In comp.arch Zalman Stern wrote: : : The position above is the one taken by Wirth in his mid to late 80's CACM : : paper on computer architecture. : To clarify, this last sentence is about Tim's claim that instruction : bandwidth concerns argue for a CISCier instruction set. Wirth's paper : defended a number of CISC architectures, notably the NS32032 family, : against the onslaught of RISC architectures with data that showed they : delivered superior code density. Yet these architectures continued to fall : behind in performance. The methodolgy of that paper was suspect, and obviously so even at the time. In the name of "keeping the playing field level", Wirth changed only the back-end of the original Lilith compiler. Lilith was a stack machine wherein such things as common subexpression elimination were less useful, hence not part of the "middle" of the compiler. It also had a single conditional branch, so if ( x < y ) { ... some code ... } was always turned into boolean cond = (x < y); if ( cond ) { ... some code ... } The "modified back ends" did a fairly straight-forward translation of "intermediate code" (that looked a _lot_ like Lilith instructions) into target instructions, usually (always?) one at a time. (All this is from memory of the original paper, but I definitely recall "smelling a rat" when I first read it, and I was nowhere near as cynical then...) IIRC, he didn't even bother to do any register allocation (with the _possible_ exception of a single "accumulator" to cache the "top of stack") So, who here believes that taking, say, the x86 assembly resulting from an x86 compiler, and translating it one instruction at a time into IA64 code _wouldn't_ show the x86 to be superior? Wirth was basically testing "How closely does this architecture resemble my original target" : (Some will point out that CISC is still dominant marketwise. IIRC, the 386 : was behind Lilith, the NS32032, and the 68k in terms of code density. x86 : code density has also likely decreased slightly over the last decade due to : favoring simpler instruction sequences.) The x86 in Wirth's paper was the 8086. Say what you will about x86 where x >= 3, they are one heckuva lot easier to program than the original, and would likely have made a better showing in Wirth's test. Mike | albaugh@agames.com, speaking only for myself ###### From: samiam@cisco.com (Scott A. spam-me-some-moore) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 16:41:54 GMT Organization: Cisco.com Lines: 70 Message-ID: <7lg5oi$pl2$1@news-sj-2.cisco.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> NNTP-Posting-Host: samiam-dsl3.cisco.com Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII X-Newsreader: WinVN 0.99.9 (Released Version) (x86 32bit) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!nntp.abs.net!newsfeed.fast.net!uunet!ffx.uu.net!in5.uu.net!news-master.cisco.com!not-for-mail In article <377AA378.72CC66A9@trailing-edge.com>, shoppa@trailing-edge.com says... ;> ;>Scott A. spam-me-some-moore wrote: ;>> Don't shoot me, but at the time of the Western Digital P-Machine ;>> (which by the way was a PDP-11 chipset with different microcode) ;>> there was a small article in a magazine stating that the benchmarks ;>> for the chip were not spectacular compared to a standard machine ;>> of the time (like 68000) running code compiled conventionally. ;> ;>The "time" of the Western Digital chipset that made the PDP-11/03 ;>and the P-Engine was mid-1970's. Certainly they weren't hot performers ;>compared to later micros like 68000's, but they did compare nicely ;>against the contemporaneous micros (8080A, 6800, F8, 1802, etc.) ;> Performing a web lookup on that was not forthcoming with a date for the microengine. The LSI-11 chipset is dated 1976, which probally dates the Microengine to 1978, and the "performance" article I was talking about was after the microengine was out and in use, about 1979-1980, well within the life of the 68000. Pedantic mode off. ;>It was extremely common at the time on minicomputers to compile ;>source code into "threaded code", minimizing memory requirements ;>in exchange for slightly longer execution time. Many mini's of the ;>mid-70's were already hitting up their address space limitations and ;>compact code was a prime concern. I did one of those, but it was not for memory space reasons, just because it was easier to generate code. The only extensive threaded implementation in use then was Forth. C was mostly compiled, badly, but then C belongs more to the 1980s than 1970s. The main comparitor for the P-machine would have been Pascal/MT+, at least on micros. It generated real code. Incidentally, my compiler beat it by 2-1 margins. ;> ;>> It brings to mind the proverb: "The first thing you learn from history ;>> is that no one learns from history".... The Java machine (hardware ;>> chip to execute bytecode) project is now twisting in the wind, with ;>> most of the fabs who initally stating support putting off actual ;>> silicon indefinately. ;>> ;>> When I entered programming, one of the leading designers of the ;>> day stated that we would be building "more machines within machines" ;>> with reference to the 8086 being based on Microcode vs the old ;>> random logic method. ;>> ;>> Even Intel has realized that this is heading downtown against ;>> traffic. The rule now is that real execution at hardware is a platform ;>> that is going down, down, to lower and lower levels of execution, ;>> with software bridging the gap. ;> ;>This isn't so obvious these days. After all, isn't instruction ;>stream bandwidth an important consideration? If so, history may ;>see us swinging towards CISCier instruction sets yet again. ;> Its a memory issue. The theory is that given you can use a wide bus path to memory to hold multiple instructions, you can get conventional CISC to run as fast as RISC as long as the total memory bandwidth is less than the time to process instructions, which is going to be less with RISC. Although I could argue that you can allways go to static ram if you want to run up against the per-instruction wall, it seems we are up against the wall even with dram memory. The view of a very wide dram path is typified by Intels IA64: use the multiple instruction ability to perform parallel pathing, and go RISC for the instructions. >Tim. ###### From: glass2@glass2.lexington.ibm.com Newsgroups: alt.folklore.computers Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 17:03:41 GMT Organization: IBM Austin Lines: 29 Message-ID: <7lg71d$1442$1@ausnews.austin.ibm.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7lf9gb$isg@grimer.diku.dk> Reply-To: glass2@glass2.lexington.ibm.com NNTP-Posting-Host: glass2.cv.lexington.ibm.com X-Newsreader: IBM NewsReader/2 2.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!howland.erols.net!portc02.blue.aol.com!nyd.news.ans.net!abq.news.ans.net!znr.news.ans.net!news.chips.ibm.com!newsfeed.btv.ibm.com!rtpnews.raleigh.ibm.com!ausnews.austin.ibm.com!not-for-mail In <7lf9gb$isg@grimer.diku.dk>, torbenm@diku.dk (Torben AEgidius Mogensen) writes: > >The "Perq" workstation from Three Rivers used a microprogrammable chip >which was microcoded to run P-code. > >The Rekursiv processor was designed to run a language called LINGO. > >Neither of these can, however, be said to execute the HLL directly, >but they do execute a form that is close to the HLL. > >One can, however, wonder if there is much difference between a CPU >that is microcoded to run a HLL and a RISC CPU that runs an >interpreter for a HLL, especially if the interpreter is stored in ROM. > > Torben Mogensen (torbenm@diku.dk) While this doesn't apply directly to the subject of running a high level language directly in the microcode, I seem to remember that there was a machine in the early 1960s that had a custom set of microcode for each language that was being run. For example, one set of microcode would be used to run an application written in Fortran, and another set would be used for an application written in Cobol, etc. I think it was a Burroughs machine, but my memory is a bit fuzzy. Dave P.S. Standard Disclaimer: I work for them, but I don't speak for them. ###### Newsgroups: alt.folklore.computers,comp.arch From: jkenton@world.std.com (Jeff Kenton) Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Message-ID: Date: Thu, 1 Jul 1999 18:10:01 GMT References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> Organization: Jeff Kenton Lines: 20 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!fu-berlin.de!news.fh-hannover.de!news-han1.dfn.de!news-koe1.dfn.de!do.de.uu.net!uunet!ams.uu.net!ffx.uu.net!world!jkenton samiam@cisco.com (Scott A. spam-me-some-moore) writes: >;>It was extremely common at the time on minicomputers to compile >;>source code into "threaded code", minimizing memory requirements >;>in exchange for slightly longer execution time. Many mini's of the >;>mid-70's were already hitting up their address space limitations and >;>compact code was a prime concern. >I did one of those, but it was not for memory space reasons, just >because it was easier to generate code. The only extensive threaded >implementation in use then was Forth. C was mostly compiled, badly, >but then C belongs more to the 1980s than 1970s. Fortran on PDP-11s was threaded in the 70s. -- ------------------------------------------------------------------------- = Jeff Kenton jkenton@world.std.com = ------------------------------------------------------------------------- ###### From: albaugh@agames.com (Mike Albaugh) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Followup-To: alt.folklore.computers,comp.arch Date: 1 Jul 1999 18:19:00 GMT Organization: Atari Games Corporation Lines: 26 Message-ID: <7lgbek$105$1@null.agames.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> NNTP-Posting-Host: java.agames.com X-Trace: null.agames.com 930853140 1029 192.245.83.156 (1 Jul 1999 18:19:00 GMT) X-Complaints-To: abuse@agames.com NNTP-Posting-Date: 1 Jul 1999 18:19:00 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!nntp.abs.net!newshub2.home.com!news.home.com!newshub1-work.home.com!null!albaugh Scott A. spam-me-some-moore (samiam@cisco.com) wrote: : ;>It was extremely common at the time on minicomputers to compile : ;>source code into "threaded code", minimizing memory requirements : ;>in exchange for slightly longer execution time. Many mini's of the : ;>mid-70's were already hitting up their address space limitations and : ;>compact code was a prime concern. : I did one of those, but it was not for memory space reasons, just : because it was easier to generate code. The only extensive threaded : implementation in use then was Forth. The Fortran compiler for the PDP-11 line (Not the "special" for 45-class CPUs, but the "normal" one) used threaded code. Partly for space reasons, but mainly to make it easier to mask the differences in models, especially floating point. The "virtual machine" was sufficiently simple that I toyed with the idea of writing a "library" in 6502 assembly, and linking it with the .obj's of the Colossal Cave, compiled by the RT-11 Fortran compiler. That was before they started sprinkling small "native code" stamps through the threaded stuff, and somehow, real work intervened... A good overview of this compiler is "Turning cousins into sisters", in the DEC book "Computer Engineering". ob. comp.arch, this book probably belongs on the average comp.arch readers bookshelf. Mike | albaugh@agames.com, speaking only for myself ###### From: koopman@cmu.edu (Philip Koopman) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 01 Jul 1999 19:41:36 GMT Organization: Carnegie Mellon University, ECE & ICES Lines: 23 Message-ID: <377fc3c8.2125105@news.ece.cmu.edu> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lftqd$bbm$1@yama.mcc.ac.uk> Reply-To: koopman@cmu.edu NNTP-Posting-Host: besugo.rem.cmu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!howland.erols.net!newsfeed.cwix.com!192.232.20.2!malgudi.oar.net!news.ysu.edu!news.ece.cmu.edu!not-for-mail glmar04@swirl.mcc.ac.uk (Geoff Lane) wrote: >Once saw a paper describing a h/w system that ran Fortran. Might have been >in CACM 25 odd years ago. The one I know about is: Chen, Y., Chen, K. & Huang, K. (1980) Direct-execution high-level language FORTRAN computer. In: Proc. of the Int. Workshop on High-Level Language Computer Architecture, Fort Lauderdale FL, 26-28 May 1980, pp. 9-16 ------------------------- Several high level language machines are also summarized at: http://www.ices.cmu.edu/koopman/stack_computers/appa.html ------------------------ -- Phil Phil Koopman -- koopman@cmu.edu -- http://www.ece.cmu.edu/~koopman ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 1 Jul 1999 20:20:10 GMT Organization: Netcom Lines: 28 Message-ID: <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Thu Jul 01 3:20:10 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!howland.erols.net!ix.netcom.com!not-for-mail In comp.arch Chris Morgan wrote: : Just after I got my head around how multi-threaded programs are : executed on a single normal CPU, I read about a cpu that had all the : Ada tasking primitives implemented in hardware. Perhaps that kind of : thing will come again for Java. Multi-threaded hardware is threatening to make big inroads for perormance reasons as a method of tolerating memory latency. This will not be one of those "semantic gap" excercises. Nor do I think Java will much influence the flavor of this kind of hardware. There are lots of good papers on www.tera.com and a search for "simultaneous multithreading" should land you at the University of Washington where a different tack is being researched. Alpha is said to be heading in the simultaneous multithreading direction. I have not read any technical papers on the IBM dual thread implementation of PowerPC64. The Tera papers are particularly interesting for looking at the software environment issues. Especially multilevel scheduling for both processors and physical memory resources. I think it was one of the San Diego papers which mentioned how many cycles the MTA takes to fire off a thread from the program's point of view. Its something like 8k cycles in the "got a free thread cached" case and >20k cycles otherwise. This struck me as a couple of orders of magnitude larger than I expected given hardware support for thread creation and scheduling. Further proof that nothing is as good as you expect :-) -Z- ###### From: nailed_barnacleSPAMFREE@hotmail.com (barnacle) Newsgroups: alt.folklore.computers Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 01 Jul 1999 20:26:24 GMT Organization: [posted via Easynet Ltd] Lines: 27 Message-ID: <7lgiq4$29at$1@quince.news.easynet.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7le2ur$mp1$1@null.agames.com> NNTP-Posting-Host: nbarnes.easynet.co.uk X-Trace: quince.news.easynet.net 930860676 75101 194.154.98.206 (1 Jul 1999 20:24:36 GMT) X-Complaints-To: abuse@easynet.net NNTP-Posting-Date: 1 Jul 1999 20:24:36 GMT X-Newsreader: News Xpress 2.01 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!cam-news-hub1.bbnplanet.com!nyc-news-feed1.bbnplanet.com!news.gtei.net!easynet-tele!easynet.net!quince.news.easynet.net!egbert In article <7le2ur$mp1$1@null.agames.com>, albaugh@agames.com (Mike Albaugh) wrote: --snip-- > >: If you don't want to be to technical about it, the basic-stamp single chip >: computers directly execute BASIC although it is via a ROM and an F8 (?) >: microprocessor instead of microcode. > > PIC, actually. Does the stamp just re-parse every line every time >(ala Tiny Basic), or does it tokenise on entry, as most BASICs do? > --snip-- It appears (at least with the early versions) that the compilation occurs on a PC and that the compiled version is then squirted into on-board eeprom. A syntactically incorrect program cannot be downloaded - which I suppose saves the space for error catching. It's a surprisingly versatile beastie...I built a series of widgets which synchronised audio switching across a data link which came and went, with a variable delay of several seconds, and a bit budget measured in bits per minute. On top of that, both ends of the link had to be identical units... -- barnacle http://www.nbarnes.easynet.co.uk ###### From: Toon Moene Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 01 Jul 1999 21:05:22 +0200 Organization: Moene Computational Physics, Maartensdijk, The Netherlands Lines: 22 Message-ID: <377BBBF2.3807C588@moene.indiv.nluug.nl> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lftqd$bbm$1@yama.mcc.ac.uk> NNTP-Posting-Host: mail.moene.indiv.nluug.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: zonnetje.NL.net 930855976 21039 195.109.255.217 (1 Jul 1999 19:06:16 GMT) X-Complaints-To: abuse@nl.uu.net NNTP-Posting-Date: 1 Jul 1999 19:06:16 GMT X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!remarQ-easT!supernews.com!remarQ.com!newsfeed2.news.nl.uu.net!sun4nl!zonnetje.nl.net!not-for-mail Geoff Lane wrote: > Once saw a paper describing a h/w system that ran Fortran. Might have been > in CACM 25 odd years ago. I wonder what the use of that would be (note: 25 years ago means Fortran 66). The only thing "Fortran Hardware" needs to do is arithmetic on floating point data and some integer arithmetic (mostly add/subtract) for accessing array elements. Perhaps the most difficult flow of control construct is assigned goto, because that needs a jump-to-address-in-register-or-memory. Hardly worth making special hardware for ... -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html ###### From: Juergen Nickelsen Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 01 Jul 1999 21:46:00 +0200 Organization: [Posted via] Interactive Networx Lines: 17 Sender: nickel@goting.jn.berlin.snafu.de Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: n34-121.berlin.snafu.de X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" In-Reply-To: Tim Shoppa's message of "Wed, 30 Jun 1999 16:30:51 GMT" Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!unlisys!news.snafu.de!goting.jn.berlin.snafu.de!nobody Tim Shoppa writes: > There's the LISP Engine, but I don't know if it internally stored > the code in human-readable or tokenized form. As far as I know, the Lisp machines of MIT ancestry (LMI, Symbolics, TI Explorer(?)) have a highly optimizing compiler, only the hardware is tuned to execute the operations most frequently Lisp very fast -- consing cells, accessing elements of a cell, calling functions, etc. Closer to the execution of ASCII text would be the Novix Forth chip, which, IIRC, executes several basic Forth operators after little (if at all) more than tokenization. But surely others can say more about it. (Communa?) -- Juergen Nickelsen ###### From: Keith Wootten Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 1 Jul 1999 22:09:10 +0100 Organization: Dragonfly Designs Message-ID: <8i7U6AA2j9e3EwgY@wootten.demon.co.uk> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: wootten.demon.co.uk X-NNTP-Posting-Host: wootten.demon.co.uk:158.152.108.134 X-Trace: news.demon.co.uk 930863444 nnrp-07:4376 NO-IDENT wootten.demon.co.uk:158.152.108.134 X-Complaints-To: abuse@demon.net MIME-Version: 1.0 X-Newsreader: Turnpike (32) Version 4.01 <7r9OMDU2ooRJCQmjnAJhyBtDT4> Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!news0.de.colt.net!colt.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!wootten.demon.co.uk!Keith In article , Juergen Nickelsen writes [snip] > >Closer to the execution of ASCII text would be the Novix Forth chip, >which, IIRC, executes several basic Forth operators after little (if >at all) more than tokenization. But surely others can say more about >it. (Communa?) > Novix is long gone, its successor the Harris RTX2000 was discontinued more recently. The PSC1000 (32bit 100MHz $10 stack machine at www.ptsc.com) executes many Forth instructions directly, which makes low-level debugging blissful. Ok, maybe 'blissful' is an overstatement... Cheers -- Keith Wootten ###### Date: Thu, 01 Jul 1999 22:14:27 +1200 From: newbery@actrix.gen.nz (Newbery Family) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> Organization: Newbery family X-Newsreader: MT-NewsWatcher 2.4.1 X-Face: 8:ZZ)2(/!={.a"'=F7@urlu,!Hj=,hZ!IA>j|2\)l ZSNeVO&Q@FG_h6(p-kyEC.=%PRgtP7 NNTP-Posting-Host: 202.36.204.181 X-Original-NNTP-Posting-Host: 202.36.204.181 X-Trace: 1 Jul 1999 22:14:28 NZST, 202.36.204.181 Lines: 14 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!ihug.co.nz!news.iprolink.co.nz!news.actrix.gen.nz!newbery In article <377A0DF8.1E1FAFE9@trailing-edge.com>, Tim Shoppa wrote: >Well, not ASCII, but weren't there some machines in the 1960's >that directly executed high-level languages (Algol?) in source >form (probably EBCDIC or maybe tokenized)? I suspect you are thinking of the Burroughs Large Systems that were targeted towards Algol 60 and never had an assembler. These were/are tag & stack architecture machines, but they still used machine code---they just didn't ever bother with an assembler. OTOH, there was always the never-to-be-sufficiently-damned IBM Series/1, which used an assmbler (EDL) that generated code which was then interpreted. ###### From: Chris Morgan Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 02 Jul 1999 08:08:53 -0400 Organization: Linux Hackers Unlimited Lines: 47 Sender: cm@mihalis.ix.netcom.com Message-ID: <874sjnw8x6.fsf@mihalis.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> NNTP-Posting-Host: a5.f7.2b.0e X-Server-Date: 2 Jul 1999 12:06:53 GMT X-Newsreader: Gnus v5.5/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.cwix.com!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!not-for-mail Zalman Stern writes: > Multi-threaded hardware is threatening to make big inroads for perormance > reasons as a method of tolerating memory latency. This will not be one of > those "semantic gap" excercises. Nor do I think Java will much influence > the flavor of this kind of hardware. It might happen the other way around - if a subset of a multi-threaded language maps on to real hardware threads, I know I would be tempted to try and live within the subset, e.g. in Ada just using the pthreads like mechanisms (protected data structures) rather than the full "rendezvous" mechanism. > > There are lots of good papers on www.tera.com and a search for > "simultaneous multithreading" should land you at the University of > Washington where a different tack is being researched. Alpha is said to be > heading in the simultaneous multithreading direction. I have not read any > technical papers on the IBM dual thread implementation of PowerPC64. Thanks for the tip, I had thought there wouldn't be (yet) much published. The Alpha SMT stuff in 21464 sounded interesting from the hints in this group, but that chip is a long way off. > > The Tera papers are particularly interesting for looking at the software > environment issues. Especially multilevel scheduling for both processors > and physical memory resources. I think it was one of the San Diego papers > which mentioned how many cycles the MTA takes to fire off a thread from the > program's point of view. Its something like 8k cycles in the "got a free > thread cached" case and >20k cycles otherwise. This struck me as a couple > of orders of magnitude larger than I expected given hardware support for > thread creation and scheduling. Further proof that nothing is as good as > you expect :-) I don't think that's much better than doing it in software! For some problems though, multi-threaded is just easier for the programmer. I'm convinced X Window event handling would have been nicer if designed for multi-threaded environments. Chris -- Chris Morgan Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages ) Date: 02 Jul 1999 23:44:25 +0200 Organization: My own Private Self Lines: 62 Sender: neil@chonsp.franklin.ch Message-ID: <6uwvwig212.fsf@chonsp.franklin.ch> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> X-Newsreader: Gnus v5.3/Emacs 19.34 Juergen Nickelsen writes: > > Closer to the execution of ASCII text would be the Novix Forth chip, > which, IIRC, executes several basic Forth operators after little (if > at all) more than tokenization. But surely others can say more about > it. (Communa?) Actually not. The NC4000 (like Lisp machines, AFAIK) executes address lists interspersed with opcodes for primitive operations. The NC4000 codes 0000-7FFF stand for CALL to the named memory word (the chip adresses 64k*16, but programs can only be in the lower half of memory). 8000-FFFF are directly executed with each bit driving the various gates in the CPU with the bits->gates formula depending on the 8xxx-Fxxx for the exact meaning (8 ALU Op, 9 cond branch, A decr and branch, B uncond branch, C register->stack, D st->reg, E mem->st, F st->mem). For ALU Ops it is: Bit 15-12 = 8, 11-9 operation (0 nop, 1 and, 2 -, 3 or, 4 +, 5 xor, 6 swap -, 7 swap), 8-7 select 2nd operand source, 6 parallel copy acc to operand, 5 tag on an return, 4 move stack, 3 double shift width, 2 make subtraction conditional (for divisions) 1-0 shift opertion. For all branches bit 11-0 is an 12 bit replacement for the lower bits in the instruction pointer (not relative offset!). Jumping between 4kword pages is only possible as part of an call or return. Note that in Forth jumps only happen inside subroutines, which are generally short (seldom over 16 words). The compiler is entirely in software and takes words (symbols) and compiles them to opcodes or calls. All secondary words (subroutines, this includes mul/div) are compiled to an 1 word call, the last call and return pair are optimised to an jump. All primitives are directly compiled as inlined operations and the last one integrates the return bit. The chip the directly executes all codes at 1 instruction per clock (with the exemption of loss du to mem<->stack transfers). Details are from: Footsteps in an Empty Valley - nc400 single chip forth engine by C.H.Ting, 1986 And no, I never had an nc4000, they cost $10,000 in the days I would have been interested (due to US export restrictions, and military background check needed). This was later dropped and they came down to about $500 just as I discovered the Transputer (32bits and parallel), so I went for that. -- Neil Franklin, Nerd, Geek, Unix Wizzard and Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Computer: toy that speeds work, so you have more time to play with it ###### From: brian@shapes.demon.co.uk (Brian Drummond) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: Fri, 02 Jul 1999 14:19:31 GMT Message-ID: <3788c391.101800992@news.demon.co.uk> References: <377e670a.12577535@news.demon.co.uk> <7lgr35$83a$3@news1.cableinet.co.uk> NNTP-Posting-Host: shapes.demon.co.uk X-NNTP-Posting-Host: shapes.demon.co.uk:158.152.228.158 X-Trace: news.demon.co.uk 930924912 nnrp-03:18250 NO-IDENT shapes.demon.co.uk:158.152.228.158 X-Complaints-To: abuse@demon.net X-Newsreader: Forte Agent 1.5/32.452 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 32 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!dispose.news.demon.net!demon!news.demon.co.uk!demon!shapes.demon.co.uk!not-for-mail On 1 Jul 1999 22:45:57 GMT, euphrates@freenet.co.uk wrote: > > >On 1999-07-01 brian@shapes.demon.co.uk(BrianDrummond) said: > :LINGO lives on, though only as a curiosity (as far as I know ...?) > > :I still have a 16-bit DOS implementation that never quite got > :finished - apart from persistent storage and windows, it's complete > :(including GC) and runs just fine - a bit faster, on my 200MHz > :Pentium, than on the 6MHz (microcode, about 2M Lingo > :instructions/second) Rekursiv. > > :It's still the easiest tool I have for solving a few problems. > >Oooh... is it freely available? I tried to get the rights to put at least the 16-bit crippleware (DOS!!) version to put it in the public domain, but no such luck. A shame because it was a nice little language, full dynamic binding, rather like Smalltalk but without the awkward (at least to me!) syntax. Mine was an interactive compiler (to 8086 code!) and runtime system - with compacting GC, you still has about 400k of object space out of your 640k! Maybe I should talk to Ivor Tiefenbrun again, but at this stage I doubt it would be competitive with anything :( - Brian ###### From: euphrates@freenet.co.uk Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 2 Jul 1999 19:07:15 GMT Organization: Cable Internet (post doesn't reflect views of Cable Internet) Lines: 47 Message-ID: <7lj2l3$9jv$1@news1.cableinet.co.uk> References: NNTP-Posting-Host: 212.1.150.151 X-Trace: news1.cableinet.co.uk 930942435 9855 212.1.150.151 (2 Jul 1999 19:07:15 GMT) X-Complaints-To: abuse@cableinet.net NNTP-Posting-Date: 2 Jul 1999 19:07:15 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!fu-berlin.de!news-feed1.de1.concert.net!news-feed1.eu.concert.net!btnet-peer!btnet!news5.cableinet.net!cableinet-uk!news1.cableinet.co.uk!not-for-mail On 1999-07-01 Juergen Nickelsen said: :Closer to the execution of ASCII text would be the Novix Forth chip, :which, IIRC, executes several basic Forth operators after little (if :at all) more than tokenization. But surely others can say more about :it. (Communa?) Happy to oblige. :> The Novix chip was criticised by its designer, Chuck Moore (who came up with Forth in the first place) for being quite a poor fit to the Forth primitive set. You could combine several primitives into one word, and you didn't need that much optimisation, but the compiler was inherently non-portable to other architectures. (That compiler, cmForth, is still available in text form; www.forth.org wil get you to it.) However, it did have the pleasant attribute that high level calls were indicated by a single bit set in the instruction word, which made high-level Forth look as you'd expect it to (a list of addresses). After that effort, Chuck had a bit of a rethink, and the ShBoom resulted; this was a much better match to Forth, and had 4 8-bit primitive slots per word. Aside from calls, there was a pretty much 1 to 1 correspondence between Forth source and ShBoom object code. Then he had more of a rethink, ditched all but 22 Forth primitives, separated out an address gate, and came up with the 20-bit P21 core, which has 4 5-bit wide slots per word (www.ultratechnology.com). However, Chuck's wasn't the only Forth engine around at the time; there were other efforts, and the one I liked most (from the design standpoint, having never used one) was Phil Koopman's WISC/16. Basically, the instruction word was a 16-bit wide address, but if the top 8 bits were 1, the bottom 8 bits indexed into a writable microcode memory and executed a primitive. Which, of course, meant you could write your own primitives on the fly - always nice. :> Koopman's complete book on stack machines can be found at his website, and if you're interested makes fascinating reading. He also has some papers there about efficient translation of languages like C for a stack machine, which could also be worth a read. I can't remember the URL, but you can get there from www.forth.org . And of course, the sheer simplicity of a stack machine means it's a triviality to stick one inside an FPGA - people seem to be quite keen on using Xilinx chips for this, and I really must do so myself at some point. -- Communa -- you know soft spoken changes nothing ###### From: euphrates@freenet.co.uk Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 2 Jul 1999 19:07:19 GMT Organization: Cable Internet (post doesn't reflect views of Cable Internet) Lines: 20 Message-ID: <7lj2l7$9jv$2@news1.cableinet.co.uk> References: <8i7U6AA2j9e3EwgY@wootten.demon.co.uk> NNTP-Posting-Host: 212.1.150.151 X-Trace: news1.cableinet.co.uk 930942439 9855 212.1.150.151 (2 Jul 1999 19:07:19 GMT) X-Complaints-To: abuse@cableinet.net NNTP-Posting-Date: 2 Jul 1999 19:07:19 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-was.dfn.de!nntp-out.monmouth.com!newspeer.monmouth.com!colt.net!newspeer.clara.net!news.clara.net!news-lond.gip.net!news.gsl.net!gip.net!news5.cableinet.net!cableinet-uk!news1.cableinet.co.uk!not-for-mail On 1999-07-01 Keith@wootten.demon.co.uk said: :Novix is long gone, its successor the Harris RTX2000 was :discontinued more recently. The PSC1000 (32bit 100MHz $10 stack :machine at www.ptsc.com) executes many Forth instructions directly, :which makes low-level debugging blissful. :Ok, maybe 'blissful' is an overstatement... :> The real irony of the PSC1000 is that they're pushing it as a Java chip, despite the fact that even a cursory glance at the instruction set will let anyone know that Java was really not the intended target of this chip. On the other hand, it can do stack frames, and so probably wouldn't be a bad target for a C compiler. (Was it you who sent me a copy of their PSC1000 Forth cross-compiler, Keith?) -- Communa -- you know soft spoken changes nothing ###### Message-ID: <377CC28F.C509CA6B@webnexus.com> From: Samuel Paik Organization: spatial dexyne X-Mailer: Mozilla 4.08 [en] (Win98; U) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> <874sjnw8x6.fsf@mihalis.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 13 NNTP-Posting-Host: 209.140.230.197 X-Trace: typ22b.nn.bcandid.com 930922985 209.140.230.197 (Fri, 02 Jul 1999 09:43:05 EDT) NNTP-Posting-Date: Fri, 02 Jul 1999 09:43:05 EDT Date: Fri, 02 Jul 1999 06:45:51 -0700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!nntp.flash.net!hub1.ispnews.com!typ22b.nn.bcandid.com.POSTED!not-for-mail Chris Morgan wrote: > Thanks for the tip, I had thought there wouldn't be (yet) much > published. The Alpha SMT stuff in 21464 sounded interesting from the > hints in this group, but that chip is a long way off. You should also check around for papers on the Stellar GS1000/2000 and Burton Smith's HEP and Horizon. A little more remote, check out the INMOS Transputer. -- Samuel S. Paik | http://www.webnexus.com/users/paik/ 3D and multimedia, architecture and implementation Solyent Green is kitniyot! ###### From: slaur@utu.fi (Sam Laur) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 2 Jul 1999 18:16:32 GMT Organization: University of Turku, Finland Lines: 19 Message-ID: <7livm0$p2$1@news.utu.fi> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> NNTP-Posting-Host: alya.utu.fi X-Trace: news.utu.fi 930939392 802 130.232.2.13 (2 Jul 1999 18:16:32 GMT) X-Complaints-To: usenet@news.utu.fi NNTP-Posting-Date: 2 Jul 1999 18:16:32 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!news-fra.pop.de!newsfeed.tli.de!news.algonet.se!newsfeed1.telenordia.se!algonet!newsfeed1.funet.fi!newsfeed3.funet.fi!news.utu.fi!slaur wrote: >If you don't want to be to technical about it, the basic-stamp single chip >computers directly execute BASIC although it is via a ROM and an F8 (?) >microprocessor instead of microcode. Then it would be much like comparing it to any home computer of the 80's with BASIC on ROM. F8? Ooh, dear. I have a manual "A Guide to Programming the Fairchild F-8 Microcomputer" dated 1975. A sort of multi-chip microprocessor, it sure doesn't look pretty. Sure, it has 64 general-purpose registers, try to find that in any of the other microprocessors of the era (1802 had 16, but that's still way short.) It still has an accumulator, so the registers are more like local RAM than anything else. I suppose somebody here has actually seen one (and programmed it) so I won't bad-mouth it any more :) -- /* Sam Laur slaur@utu.fi */ /* Carpe noctem! Carpe tenebras! */ ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 2 Jul 1999 19:12:10 GMT Organization: Netcom Lines: 9 Message-ID: <7lj2ua$k1d@dfw-ixnews12.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7livm0$p2$1@news.utu.fi> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Fri Jul 02 2:12:10 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!ix.netcom.com!not-for-mail In comp.arch Sam Laur wrote: : Then it would be much like comparing it to any home computer of the 80's with : BASIC on ROM. Not really. Most of those machines were happy to boot something else if the right boot sector was on a disk. People have built machines where the ROMs make it impossible for another OS to get control of the machine. -Z- ###### Newsgroups: alt.folklore.computers,comp.arch From: jkenton@world.std.com (Jeff Kenton) Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Message-ID: Date: Fri, 2 Jul 1999 19:23:02 GMT References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7livm0$p2$1@news.utu.fi> Organization: Jeff Kenton Lines: 20 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!fu-berlin.de!newsfeed.nacamar.de!tank.news.pipex.net!pipex!uunet!ams.uu.net!nyc.uu.net!ffx.uu.net!world!jkenton slaur@utu.fi (Sam Laur) writes: >F8? Ooh, dear. I have a manual "A Guide to Programming the Fairchild F-8 >Microcomputer" dated 1975. A sort of multi-chip microprocessor, it sure >doesn't look pretty. Sure, it has 64 general-purpose registers, try to >find that in any of the other microprocessors of the era (1802 had 16, but >that's still way short.) It still has an accumulator, so the registers are >more like local RAM than anything else. I suppose somebody here has >actually seen one (and programmed it) so I won't bad-mouth it any more :) I wrote a cross-assembler for it when it first came out, but never wrote any real code for it. I remember thinking it looked like an ugly beast to program. I think they had uses for industrial control, and (perhaps) car engines. -- ------------------------------------------------------------------------- = Jeff Kenton jkenton@world.std.com = ------------------------------------------------------------------------- ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 2 Jul 1999 19:56:25 GMT Organization: Netcom Lines: 34 Message-ID: <7lj5h9$k1d@dfw-ixnews12.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> <874sjnw8x6.fsf@mihalis.ix.netcom.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Fri Jul 02 2:56:25 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!fu-berlin.de!news.maxwell.syr.edu!ix.netcom.com!not-for-mail In comp.arch Chris Morgan wrote: : It might happen the other way around ["multithreaded languages" spur hardware development.] Not very likely at all. In fact, the idea that languages drive hardware is way overplayed. The successful languages do across the scale of decades, but otherwise not. Multithreaded hardware will be successful (if it is successful) because it addresses performance problems with existing environments. Over time software techniques may change to better match the hardware, but that will happen later. In case its not clear, I think this is a good thing. It greatly enhances the chance that multithreaded hardware will happen. As opposed to something which *requires* Java or Ada in which case you're talking economic obscurity. : I don't think that's much better than doing it in software! For some : problems though, multi-threaded is just easier for the : programmer. I'm convinced X Window event handling would have been : nicer if designed for multi-threaded environments. The Tera MTA can thread switch among 128 threads (per processor) on each cycle. This is much better than software can do. Its the initial thread setup time I was posting about, which is indeed comparable to software threads. There's a section in Neal Stephenson's _Cryptonomicon_ where he talks about bandsaws and a Vickers machine gun as machines which handle load without degrading at all in performance. That's what Tera is trying to do. In theory, an MTA-8 should handle 1024 threads of control just as gracefully as it handles 1. (And implicitly, it should handle 1 pretty well compared to other competition.) -Z- ###### From: Chris Morgan Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 02 Jul 1999 20:07:49 -0400 Organization: Linux Hackers Unlimited Lines: 55 Sender: cm@mihalis.ix.netcom.com Message-ID: <873dz6wq7e.fsf@mihalis.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> <874sjnw8x6.fsf@mihalis.ix.netcom.com> <7lj5h9$k1d@dfw-ixnews12.ix.netcom.com> NNTP-Posting-Host: a5.f7.2b.5a X-Server-Date: 3 Jul 1999 00:05:49 GMT X-Newsreader: Gnus v5.5/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!not-for-mail Zalman Stern writes: > In comp.arch Chris Morgan wrote: > : It might happen the other way around > ["multithreaded languages" spur hardware development.] > > Not very likely at all. In fact, the idea that languages drive hardware is > way overplayed. The successful languages do across the scale of decades, > but otherwise not. Multithreaded hardware will be successful (if it is > successful) because it addresses performance problems with existing > environments. Over time software techniques may change to better match the > hardware, but that will happen later. > > In case its not clear, I think this is a good thing. It greatly enhances > the chance that multithreaded hardware will happen. As opposed to something > which *requires* Java or Ada in which case you're talking economic > obscurity. Ah, you missed what I meant. Sorry I wasn't clear. I meant that the availability of real hardware threads might spur software development in the sense you might seem compilers for those machines map a subset of the threaded languages directly onto the SMT operations - and that I for one would be very interested in such arrangements. > > : I don't think that's much better than doing it in software! For some > : problems though, multi-threaded is just easier for the > : programmer. I'm convinced X Window event handling would have been > : nicer if designed for multi-threaded environments. > > The Tera MTA can thread switch among 128 threads (per processor) on each > cycle. This is much better than software can do. Its the initial thread > setup time I was posting about, which is indeed comparable to software > threads. Yes that's pretty nice. I'll take one! > > There's a section in Neal Stephenson's _Cryptonomicon_ where he talks about > bandsaws and a Vickers machine gun as machines which handle load without > degrading at all in performance. That's what Tera is trying to do. In > theory, an MTA-8 should handle 1024 threads of control just as gracefully > as it handles 1. (And implicitly, it should handle 1 pretty well compared > to other competition.) Spooky. I just read that on the N train hurtling down Lexington avenue. If the MTA compares to other cpus as per that analogy, I'll take one right away! Chris -- Chris Morgan References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7livm0$p2$1@news.utu.fi> <7lk5f2$dmu$1@news.igs.net> X-Trace: J6t2TCf7AberrXT6DI2ddG7ByyZt1xnZrGVqlzUvvZk= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 3 Jul 1999 11:01:35 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!news0.de.colt.net!colt.net!iad-peer.news.verio.net!news.idt.net!feed1.news.rcn.net!rcn!d14 In article <7lk5f2$dmu$1@news.igs.net>, "donald tees" wrote: >Sam Laur wrote in message <7livm0$p2$1@news.utu.fi>... > > Ooh, dear. I have a manual "A Guide to Programming the Fairchild F-8 >>Microcomputer" dated 1975. A sort of multi-chip microprocessor, it sure >>doesn't look pretty. Sure, it has 64 general-purpose registers, try to >>find that in any of the other microprocessors of the era (1802 had 16, but >>that's still way short.) It still has an accumulator, so the registers are >>more like local RAM than anything else. I suppose somebody here has >>actually seen one (and programmed it) so I won't bad-mouth it any more :) >> >Oh yes. Thousands and thousands of lines of assembler. Paper tapes. >Eproms. Prom blasters and wire wrapped memory cards. God, it was horrible. >Much more fun to execute whole computers in a network. Chuckle. Now you leave those poor network computers alone. They have enough problems without you killing them :-). /BAH Subtract a hundred and four for e-mail. ###### From: slaur@utu.fi (Sam Laur) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 3 Jul 1999 19:25:52 GMT Organization: University of Turku, Finland Lines: 13 Message-ID: <7llo40$53l$1@news.utu.fi> References: <7lassu$p2q$1@mail.pl.unisys.com> <7livm0$p2$1@news.utu.fi> <7lj2ua$k1d@dfw-ixnews12.ix.netcom.com> NNTP-Posting-Host: alya.utu.fi X-Trace: news.utu.fi 931029952 5237 130.232.2.13 (3 Jul 1999 19:25:52 GMT) X-Complaints-To: usenet@news.utu.fi NNTP-Posting-Date: 3 Jul 1999 19:25:52 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-fra.maz.net!news.algonet.se!newsfeed1.telenordia.se!algonet!newsfeed1.funet.fi!news.utu.fi!slaur Zalman Stern wrote: >Not really. Most of those machines were happy to boot something else if the >right boot sector was on a disk. People have built machines where the ROMs Hmm. Try telling that to a machine like Commodore 64, or Sinclair Spectrum, or most any other 80s home computer with BASIC on ROM and without a disk drive. The original poster was talking about the BASIC Stamp as a "BASIC-running microprocessor" which it really isn't. As little as any of those machines I mentioned. -- /* Sam Laur slaur@utu.fi */ /* Carpe noctem! Carpe tenebras! */ ###### From: Chris Morgan Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 03 Jul 1999 20:59:56 -0400 Organization: Linux Hackers Unlimited Lines: 24 Sender: cm@mihalis.mihalis.net Message-ID: <87g135w7oz.fsf@mihalis.mihalis.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> <874sjnw8x6.fsf@mihalis.ix.netcom.com> <377E844D.30F05F60@gmx.de> NNTP-Posting-Host: a5.f7.29.0a X-Server-Date: 4 Jul 1999 01:00:40 GMT X-Newsreader: Gnus v5.5/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.berkeley.edu!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!not-for-mail Bernd Paysan writes: > Chris Morgan wrote: > > I don't think that's much better than doing it in software! For some > > problems though, multi-threaded is just easier for the > > programmer. I'm convinced X Window event handling would have been > > nicer if designed for multi-threaded environments. > > What do you want? If you really like to, you could create a new > connection to the X server for every window you create. IMHO it's more > the other way round: X would be nicer if the server was multi-threaded. They're not mutually exclusive though. I've never considered the possibility of a multi-threaded server but now that you mention it, I suppose it could be really nice. Of course you would want the ability to set up timed and recurring operations on the server ("just blit this whole bitmap to the screen every vertical refresh, I will have done stuff to it in the mean, trust me"). Ok, we're agreed, threads everywhere, to hell with the single-thread of control mindset! -- Chris Morgan From: Samuel Paik Organization: spatial dexyne X-Mailer: Mozilla 4.08 [en] (Win98; U) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> <874sjnw8x6.fsf@mihalis.ix.netcom.com> <377E844D.30F05F60@gmx.de> <87g135w7oz.fsf@mihalis.mihalis.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 14 NNTP-Posting-Host: 209.140.230.197 X-Trace: typ22b.nn.bcandid.com 931067082 209.140.230.197 (Sun, 04 Jul 1999 01:44:42 EDT) NNTP-Posting-Date: Sun, 04 Jul 1999 01:44:42 EDT Date: Sat, 03 Jul 1999 22:47:40 -0700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!hermes.visi.com!news-out.visi.com!hub1.ispnews.com!typ22b.nn.bcandid.com.POSTED!not-for-mail Chris Morgan wrote: > They're not mutually exclusive though. I've never considered the > possibility of a multi-threaded server but now that you mention it, I believe there are some commerical multi-threaded X servers-- isn't there an experimental multi-threaded X server in the X Consortium distribution? I'm pretty sure that the SGI X servers are multithreaded, although most of the threads are there to handle GLX protocol streams. -- Samuel S. Paik | http://www.webnexus.com/users/paik/ 3D and multimedia, architecture and implementation Solyent Green is kitniyot! ###### From: Bernd Paysan Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Sat, 03 Jul 1999 23:44:45 +0200 Organization: Bernd Paysan, 81477 Muenchen, Germany Lines: 14 Message-ID: <377E844D.30F05F60@gmx.de> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <87r9ms4mxz.fsf@mihalis.ix.netcom.com> <7lgihq$p5r@dfw-ixnews5.ix.netcom.com> <874sjnw8x6.fsf@mihalis.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: news@paysan.nom NNTP-Posting-Date: 3 Jul 1999 21:44:45 GMT X-Mailer: Mozilla 3.0 (X11; I; Linux 2.3.5 i586) NNTP-Posting-Host: dial103.mucweb.de X-Trace: 4 Jul 1999 00:35:00 +0200, dial103.mucweb.de Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!newsfeed.ecrc.net!newsfeed2.ecrc.net!news.touch.net!granny.paysan.nom!not-for-mail Chris Morgan wrote: > I don't think that's much better than doing it in software! For some > problems though, multi-threaded is just easier for the > programmer. I'm convinced X Window event handling would have been > nicer if designed for multi-threaded environments. What do you want? If you really like to, you could create a new connection to the X server for every window you create. IMHO it's more the other way round: X would be nicer if the server was multi-threaded. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/ ###### From: "donald tees" Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Sun, 4 Jul 1999 00:59:09 -0400 Organization: IGS - Information Gateway Services Lines: 17 Message-ID: <7lk5f2$dmu$1@news.igs.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7livm0$p2$1@news.utu.fi> NNTP-Posting-Host: ttya0f.kw.igs.net X-Trace: news.igs.net 930978082 14046 216.58.99.47 (3 Jul 1999 05:01:22 GMT) X-Complaints-To: abuse@igs.net NNTP-Posting-Date: 3 Jul 1999 05:01:22 GMT X-Newsreader: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!fu-berlin.de!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.cwix.com!206.191.82.230!prairie.attcanada.net!attcanada!nntp.igs.net!news.igs.net!not-for-mail Sam Laur wrote in message <7livm0$p2$1@news.utu.fi>... Ooh, dear. I have a manual "A Guide to Programming the Fairchild F-8 >Microcomputer" dated 1975. A sort of multi-chip microprocessor, it sure >doesn't look pretty. Sure, it has 64 general-purpose registers, try to >find that in any of the other microprocessors of the era (1802 had 16, but >that's still way short.) It still has an accumulator, so the registers are >more like local RAM than anything else. I suppose somebody here has >actually seen one (and programmed it) so I won't bad-mouth it any more :) > Oh yes. Thousands and thousands of lines of assembler. Paper tapes. Eproms. Prom blasters and wire wrapped memory cards. God, it was horrible. Much more fun to execute whole computers in a network. ###### From: "John Gilmer" Newsgroups: alt.folklore.computers,comp.arch References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7livm0$p2$1@news.utu.fi> <7lk5f2$dmu$1@news.igs.net> Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Sun, 4 Jul 1999 07:08:09 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Lines: 51 Message-ID: <377f5c78$0$455@mojo.crosslink.net> NNTP-Posting-Host: 207.199.168.112 X-Trace: mojo.crosslink.net 931093624 455 207.199.168.112 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!bignews.mediaways.net!newsfeed.nacamar.de!tank.news.pipex.net!pipex!warm.news.pipex.net!pipex!ftel.ftel.co.uk!newsfeed.eris.dera.gov.uk!nntp.crosslink.net!206.246.124.71.MISMATCH!mojo.crosslink.net!not-for-mail The F-8 allowed a low on control and I/O with only two chips. It was marketed as an appliance controller but the competition got better faster than the F-8. I briefly looked into using it in 76 on some telephone equipment. It was too slow and took up a little too much room so we went to a custom IC. It was a close call, however. At another company I joined, an engineer used the F-8 as the heart of an auto-pilot for a remote controlled small (6 foot wingspan) aircraft. It worked because the A/C was stable enough that data rates (control and gyro) of 10 samples per second were adequate. One engineer working long and hard did all the work. The nature of the task, the detail, and the programming tools available made it the kind of job where if one engineer isn't enough people, you would have to have 5 or more! For the next generation, we had proposed using an 8086 (which has just come out.) The government pulled the plug and that was that. I think Fairchild had the right idea but either should have simplified the processor even more to get a system on a chip OR tried to push the circuit density a little more to accomplish the same result. JLG donald tees wrote in message news:7lk5f2$dmu$1@news.igs.net... > Sam Laur wrote in message <7livm0$p2$1@news.utu.fi>... > > Ooh, dear. I have a manual "A Guide to Programming the Fairchild F-8 > >Microcomputer" dated 1975. A sort of multi-chip microprocessor, it sure > >doesn't look pretty. Sure, it has 64 general-purpose registers, try to > >find that in any of the other microprocessors of the era (1802 had 16, but > >that's still way short.) It still has an accumulator, so the registers are > >more like local RAM than anything else. I suppose somebody here has > >actually seen one (and programmed it) so I won't bad-mouth it any more :) > > > Oh yes. Thousands and thousands of lines of assembler. Paper tapes. > Eproms. Prom blasters and wire wrapped memory cards. God, it was horrible. > Much more fun to execute whole computers in a network. > > > > ###### Message-ID: <37803BA8.6C948C9C@REMOVEhome.com> From: Scott McPhillips Organization: McPhillips Designs X-Mailer: Mozilla 4.5 [en]C-AtHome0404 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <377A6E58.2A3C5134@slip.net> <7livm0$p2$1@news.utu.fi> <7lk5f2$dmu$1@news.igs.net> <377f5c78$0$455@mojo.crosslink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 12 Date: Mon, 05 Jul 1999 04:59:54 GMT NNTP-Posting-Host: 24.3.47.220 X-Complaints-To: abuse@home.net X-Trace: news.rdc1.md.home.com 931150794 24.3.47.220 (Sun, 04 Jul 1999 21:59:54 PDT) NNTP-Posting-Date: Sun, 04 Jul 1999 21:59:54 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.abs.net!newshub2.home.com!news.home.com!news.rdc1.md.home.com.POSTED!not-for-mail > > Sam Laur wrote in message <7livm0$p2$1@news.utu.fi>... > > > > Ooh, dear. I have a manual "A Guide to Programming the Fairchild F-8 > > >Microcomputer" dated 1975. A sort of multi-chip microprocessor, it sure > > >doesn't look pretty. Sure, it has 64 general-purpose registers, try to > > >find that in any of the other microprocessors of the era (1802 had 16, but > > >that's still way short.) It still has an accumulator, so the registers are > > >more like local RAM than anything else. I suppose somebody here has > > >actually seen one (and programmed it) so I won't bad-mouth it any more :) > > > Oh yes, I have actually seen one (and programmed it) so I'll bad-mouth it a bit more. One of its most "unique" features was that the branch instructions destroyed the accumulator! Another winner was the stack, which had a max depth of two. ###### Message-ID: <3781251A.DA820CC1@loop.com> From: Michael Fleming X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7livm0$p2$1@news.utu.fi> <7lj2ua$k1d@dfw-ixnews12.ix.netcom.com> <7llo40$53l$1@news.utu.fi> <7lr3gd$931@spool.cs.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 25 Date: Mon, 05 Jul 1999 14:35:22 -0700 NNTP-Posting-Host: 207.211.62.218 X-Trace: news2.randori.com 931209900 207.211.62.218 (Mon, 05 Jul 1999 14:25:00 PDT) NNTP-Posting-Date: Mon, 05 Jul 1999 14:25:00 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newspeer1.nac.net!WCG!news2.randori.com!not-for-mail plakal@nospam-cs.wisc.edu wrote: > Well, later versions of these machines did come out with disk > drives and I think they did have some facility to automatically > start executing a program from the disk when the machine was > turned on. E.g., I know that the BBC Micro had its OS (MOS - Machine > OS) and BBC BASIC in ROM, but it would automatically execute > a particular file on a floppy in the drive when turned on. This > program could then load the binary of an OS into RAM, and you could > have your own OS (in theory). I'm not sure anyone actually > bothered to do it. > > Manoj I used a system called SuperForth 64 that did this. The Commodore then booted as a forth system with the disk drive divided into 170 Forth blocks. The blocks could be paged into ram very simply, so I had 170k to play around with. All the sound and graphics functions were available as Forth words, and it ran much faster than Basic. It was a very sweet system which beat anything I ran for ease of use and interactive responsiveness until I used Symbolics. mlf ###### From: plakal@nospam-cs.wisc.edu Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 5 Jul 1999 20:10:53 GMT Organization: University of WI, Madison -- Computer Sciences Dept. Lines: 23 Sender: Manoj Plakal Message-ID: <7lr3gd$931@spool.cs.wisc.edu> References: <7lassu$p2q$1@mail.pl.unisys.com> <7livm0$p2$1@news.utu.fi> <7lj2ua$k1d@dfw-ixnews12.ix.netcom.com> <7llo40$53l$1@news.utu.fi> NNTP-Posting-Host: cecil.cs.wisc.edu User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (SunOS/5.6 (i86pc)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!logbridge.uoregon.edu!qualcomm.com!uwvax!not-for-mail In comp.arch Sam Laur wrote: > Zalman Stern wrote: >>Not really. Most of those machines were happy to boot something else if the >>right boot sector was on a disk. People have built machines where the ROMs > Hmm. Try telling that to a machine like Commodore 64, or Sinclair Spectrum, > or most any other 80s home computer with BASIC on ROM and without a disk drive. > The original poster was talking about the BASIC Stamp as a "BASIC-running > microprocessor" which it really isn't. As little as any of those machines > I mentioned. Well, later versions of these machines did come out with disk drives and I think they did have some facility to automatically start executing a program from the disk when the machine was turned on. E.g., I know that the BBC Micro had its OS (MOS - Machine OS) and BBC BASIC in ROM, but it would automatically execute a particular file on a floppy in the drive when turned on. This program could then load the binary of an OS into RAM, and you could have your own OS (in theory). I'm not sure anyone actually bothered to do it. Manoj ###### From: euphrates@freenet.co.uk Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 6 Jul 1999 19:27:16 GMT Organization: Cable Internet (post doesn't reflect views of Cable Internet) Lines: 9 Message-ID: <7ltlak$5ls$3@news1.cableinet.co.uk> References: <37803BA8.6C948C9C@REMOVEhome.com> NNTP-Posting-Host: 212.1.150.141 X-Trace: news1.cableinet.co.uk 931289236 5820 212.1.150.141 (6 Jul 1999 19:27:16 GMT) X-Complaints-To: abuse@cableinet.net NNTP-Posting-Date: 6 Jul 1999 19:27:16 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!news0.de.colt.net!colt.net!easynet-tele!easynet.net!news5.cableinet.net!cableinet-uk!news1.cableinet.co.uk!not-for-mail On 1999-07-05 scottmcp@REMOVEhome.com said: :Oh yes, I have actually seen one (and programmed it) so I'll :bad-mouth it a bit more. One of its most "unique" features was tha Could you bad-mouth it in less than 75 characters per line, please? -- Communa -- you know soft spoken changes nothing ###### From: peter@baileynm.com (Peter da Silva) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 5 Jul 1999 23:20:35 GMT Organization: Bailey Network Management Lines: 14 Message-ID: <7lrek3$qkh@web.nmti.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> NNTP-Posting-Host: wssql01.nmti.com X-Newsreader: trn 4.0-test67 (15 July 1998) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!newsfeed.nyu.edu!ultraneo.neosoft.com!news-proxy.baileynm.com!web.nmti.com!not-for-mail In article <7lg5oi$pl2$1@news-sj-2.cisco.com>, Scott A. spam-me-some-moore wrote: >I did one of those, but it was not for memory space reasons, just >because it was easier to generate code. The only extensive threaded >implementation in use then was Forth. As has been mentioned elsewhere, DEC's Fortran on the -11 generated threaded code (direct threaded code using R1 as the IP) by default. -- In hoc signo hack, Peter da Silva `-_-' Ar rug tú barróg ar do mhactíre inniu? 'U` "Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd ###### From: euphrates@freenet.co.uk Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 7 Jul 1999 09:32:20 GMT Organization: Cable Internet (post doesn't reflect views of Cable Internet) Lines: 16 Message-ID: <7lv6r4$k6p$1@news1.cableinet.co.uk> References: <7lrek3$qkh@web.nmti.com> NNTP-Posting-Host: 212.1.149.40 X-Trace: news1.cableinet.co.uk 931339940 20697 212.1.149.40 (7 Jul 1999 09:32:20 GMT) X-Complaints-To: abuse@cableinet.net NNTP-Posting-Date: 7 Jul 1999 09:32:20 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!btnet-peer!btnet!news5.cableinet.net!cableinet-uk!news1.cableinet.co.uk!not-for-mail On 1999-07-05 peter@baileynm.com(PeterdaSilva) said: :Scott A. spam-me-some-moore wrote: :>I did one of those, but it was not for memory space reasons, just :>because it was easier to generate code. The only extensive threaded :>implementation in use then was Forth. :As has been mentioned elsewhere, DEC's Fortran on the -11 generated :threaded code (direct threaded code using R1 as the IP) by default. And I don't remember anyone mentioning this, but the Spitbol compiler for (iirc) one of the PDPs, compiling Snobol 4, used indirect threaded code. -- Communa -- you know soft spoken changes nothing ###### From: Greg Gritton Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Tue, 06 Jul 1999 17:29:40 -0700 Organization: Intel Corp. Lines: 134 Message-ID: <37829F73.8B3EEF9F@intel.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: ggritton-desk.jf.intel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!hermes.visi.com!news-out.visi.com!uunet!chi.uu.net!sea.uu.net!news.or.intel.com!usenet Tim Shoppa wrote: > jmfbahciv@aol.com wrote: > > My point about people knowing that an assembly lanaguage exists is > > so that those people have some idea of what is going on in the CPU. > > There really are people who think that it's the ASCII that is getting > > executed. > > Well, not ASCII, but weren't there some machines in the 1960's > that directly executed high-level languages (Algol?) in source > form (probably EBCDIC or maybe tokenized)? > > I believe there was also hardware developed that directly executed > APL (of course in that case the programmer does the tokenization :-) ). > > There's the LISP Engine, but I don't know if it internally stored > the code in human-readable or tokenized form. > > Of course, there's also Western Digital's chipset that directly > executed UCSD P-code, but that's a little more than tokenization. > > Tim. To a large degree, the list of machines that directly execute programming languages depends on how "directly" you mean. From the most direct to the least direct: 1. Execute ASCII (or equivalent) directly 2. Execute tokenized code directly 3. Execute a compiled form with a simple compiler (examples include byte-codes, P-code, M-code, and JVM instructions) 4. Run a normal (CISC/RISC) instruction set, with instructions added for common operations in a particular language 5. Tuned for a particular language Some examples I am familiar with are: (1) Direct ASCII - none that I know of in hardware or microcode - If you count ROM, I believe old Apple integer basic worked this way (2) Tokenized - If you count ROM, many old BASIC interpreters did this* (3) Simple compilation - Lilith executed Modula 2 compiled into "M-code" - Sun pico/micro-Java executes JVM bytecodes (was it ever produced?) - The Transputer executes a byte-code style machine code that was designed to run Occam, although it could run other languages - Xerox Alto and Dorado had microcode to execute Smalltalk bytecodes (4) Augmented instruction set - SOAR (Smalltalk on a RISC) from Berkeley This was a RISC processor with additional instructions for tag checked operations, storage checks for garbage collection, etc. - Lisp machines? (5) Tuned - Modern processors tend to be tuned to execute the C and Fortran code in SpecInt and SpecFP effeciently. I am sure there are many more examples out there. In addition, you can divide machines on whether their programming language support is based on hardware or microcode. The argument about whether specific language support is a good thing or can be successful is an interesting one. There have been examples where a processor designed to run a particular language ends up no faster than a general purpose processor for that language. However, you can argue that some of these systems have been a success by at least some criteria. Among them: - The Lilith was developed in the 70's. I worked at a place that used one in the 80's. It seemed to hold its own against the CISC workstations of its the mid 80's very well. The fact that its compiler could compile 10,000 lines per minute didn't hurt it as a program development environment either. (I was using Apple IIs and VAXs at the time that both compiled about 300 lines per minute.) - In 1988, a single transputer, running Occam (or C), could outperform the 386 (its contemorary). As a bonus, the transputer was designed to be easily networked into a parallel machine, enabling cheap parallel processing. - Smalltalk was born on the Xerox Alto and then Dorado, which were microcoded to run its bytecodes. The GUI developed there was emulated by Apple, then Microsoft, and has become the basis for the modern GUI. Many of the concepts in the Smalltalk language have been used in langages such as C++ and Java. (Interestingly enough, although not well known, Smalltalk itself has evolved into a very powerful, productive language. It is now usually based on a virtual machine, but one that is often far stabler and sometimes faster than the Java virtual machines.) Of course, if you limit yourself to one language, you are limiting the market that a chip can capture. Perhaps that is why few modern chips exclusively run one language. (However, tuning a chip to run a specific lanaguage or two, namely C and Fortran, seems to be common enough.) ------------------------------------------------------------------- Greg Gritton gregory.gritton@intel.com Definately speaking only for myself and not my employer. * Often, only a barely tokenized form was used. The Apple BASIC only tokenized keywords, and I believe the IBM PC basic was similar (although I am not sure). It interpreted variables on a character by character basis, searching a table for each variable access. It likewise built numbers out of digits each time a line was run. Tokenizing numbers and replacing variable names with pointers into the variable table would have been much more effecient. ###### From: derekn@foolabs.com (Derek B. Noonburg) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 7 Jul 1999 00:09:02 -0500 Organization: Foo Labs Lines: 31 Sender: derekn@localhost.localdomain Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> <7lu95e$d1m$1@nntp1.u.washington.edu> NNTP-Posting-Host: 205.226.158.86 NNTP-Posting-Date: Tue, 06 Jul 1999 23:08:55 CDT X-Trace: newscene.newscene.com 931320535 205.226.158.86 (Tue, 06 Jul 1999 23:08:55 CDT) X-Newsreader: Gnus v5.6.43/Emacs 20.2 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!novia!sequencer.newscene.com!not-for-mail dpeschel@u.washington.edu (Derek Peschel) writes: > Greg Gritton wrote: > > >Some examples I am familiar with are: > >(1) Direct ASCII > > - none that I know of in hardware or microcode > > - If you count ROM, I believe old Apple integer basic worked this way > > No, Apple Integer BASIC belongs in category 2 (tokenized), with Applesoft. > They both use tokens. Integer BASIC has a different set and uses slightly > different data structures. I don't have the details here, unfortunately. I'm pretty sure that Greg's footnote is accurate, i.e., it's somewhere in between categories 1 and 2: > * Often, only a barely tokenized form was used. > The Apple BASIC only tokenized keywords, and I believe > the IBM PC basic was similar (although I am not sure). > It interpreted variables on a character by character basis, > searching a table for each variable access. > It likewise built numbers out of digits each time a line was run. > Tokenizing numbers and replacing variable names with > pointers into the variable table would have been much > more effecient. I remember discovering this on the Apple, and deciphering enough to do some interesting hacking. This partially tokenized scheme made writing self-modifying BASIC code much easier :-) - Derek ###### From: dpeschel@u.washington.edu (Derek Peschel) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 7 Jul 1999 01:05:50 GMT Organization: University of Washington, Seattle Lines: 13 Message-ID: <7lu95e$d1m$1@nntp1.u.washington.edu> References: <7lassu$p2q$1@mail.pl.unisys.com> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: saul7.u.washington.edu X-Trace: nntp1.u.washington.edu 931309550 13366 (None) 140.142.17.35 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dpeschel Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!logbridge.uoregon.edu!news.u.washington.edu!dpeschel In article <37829F73.8B3EEF9F@intel.com>, Greg Gritton wrote: >Some examples I am familiar with are: >(1) Direct ASCII > - none that I know of in hardware or microcode > - If you count ROM, I believe old Apple integer basic worked this way No, Apple Integer BASIC belongs in category 2 (tokenized), with Applesoft. They both use tokens. Integer BASIC has a different set and uses slightly different data structures. I don't have the details here, unfortunately. -- Derek ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 7 Jul 1999 01:08:27 GMT Organization: Netcom Lines: 9 Message-ID: <7lu9ab$n0k@dfw-ixnews7.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Tue Jul 06 8:08:27 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!ix.netcom.com!not-for-mail In comp.arch Greg Gritton wrote: : - Xerox Alto and Dorado had microcode to execute Smalltalk : bytecodes Speaking of which, wasn't the Alto semi-multithreaded as well? As in the processor switched among some number of perhaps hardwired tasks to handle I/O and graphics as well as executing the instruction set microcode. -Z- ###### From: dpeschel@u.washington.edu (Derek Peschel) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 7 Jul 1999 05:16:50 GMT Organization: University of Washington, Seattle Lines: 34 Message-ID: <7luns2$a36$1@nntp1.u.washington.edu> References: <7lassu$p2q$1@mail.pl.unisys.com> <37829F73.8B3EEF9F@intel.com> <7lu95e$d1m$1@nntp1.u.washington.edu> NNTP-Posting-Host: saul9.u.washington.edu X-Trace: nntp1.u.washington.edu 931324610 10342 (None) 140.142.17.38 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dpeschel Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!netnews.globalip.ch!news-raspail.gip.net!news.gsl.net!gip.net!news-europe.mathworks.com!newsfeed.mathworks.com!logbridge.uoregon.edu!news.u.washington.edu!dpeschel In article , Derek B. Noonburg wrote: >dpeschel@u.washington.edu (Derek Peschel) writes: >> Greg Gritton wrote: >> >> >Some examples I am familiar with are: >> >(1) Direct ASCII >> > - none that I know of in hardware or microcode >> > - If you count ROM, I believe old Apple integer basic worked this way >> >> No, Apple Integer BASIC belongs in category 2 (tokenized), with Applesoft. >> They both use tokens. Integer BASIC has a different set and uses slightly >> different data structures. I don't have the details here, unfortunately. > >I'm pretty sure that Greg's footnote is accurate, i.e., it's somewhere >in between categories 1 and 2: > >> * Often, only a barely tokenized form was used. >> The Apple BASIC only tokenized keywords, and I believe >> the IBM PC basic was similar (although I am not sure). >> It interpreted variables on a character by character basis, >> searching a table for each variable access. >> It likewise built numbers out of digits each time a line was run. >> Tokenizing numbers and replacing variable names with >> pointers into the variable table would have been much >> more effecient. You're right. What I really meant was that Integer BASIC and Applesoft should go in the same category (whether it's 2 or "1.5" doesn't matter for the purposes of my argument) and that Integer BASIC should definitely not go in category 1. -- Derek ###### From: pw@panix.com (Paul Wallich) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Wed, 07 Jul 1999 09:41:21 -0400 Organization: PANIX Public Access Internet and UNIX, NYC Lines: 36 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> <7lu9ab$n0k@dfw-ixnews7.ix.netcom.com> NNTP-Posting-Host: pw.dialup.access.net X-Trace: news.panix.com 931354884 12704 166.84.250.178 (7 Jul 1999 13:41:24 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: 7 Jul 1999 13:41:24 GMT X-Newsreader: MT-NewsWatcher 2.4.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.cwix.com!204.59.152.222!news-peer.gip.net!news.gsl.net!gip.net!panix!news.panix.com!pw In article <7lu9ab$n0k@dfw-ixnews7.ix.netcom.com>, Zalman Stern wrote: >In comp.arch Greg Gritton wrote: >: - Xerox Alto and Dorado had microcode to execute Smalltalk >: bytecodes > >Speaking of which, wasn't the Alto semi-multithreaded as well? As in the >processor switched among some number of perhaps hardwired tasks to handle >I/O and graphics as well as executing the instruction set microcode. Yep. 16 threads: The CPU would execute whichever one had the highest priority on that given clock tick. All the threads were microcoded, including (I am pretty sure) RAM refresh. Properly speaking none of them was "hardwired" but if your (rewritable) microcode didn't include refresh, mouse/keyboard, video, disk, network and so forth, you were in trouble. (Note: the 3 Mbps rate of original ethernet was set by how fast the Alto micromachine could pump bits.) It's a little amusing to note that the emulator, the thread executing the user's program, was actually the lowest-priority thread. (Also amusing to think that Alto micromachine was something like 1600 gates -- you could build dozens of them on a single FPGA). Muse: Machines like the Alto, which put many "hardware" functions into microcode, show that the definition of "directly executing" an HLL is always at least a little fuzzy and ill-formed. On the one hand you're not directly executing the user's program, but on the other, if you accept that definition you're not directly executing RAM refresh or video display either. paul ObTrivia: Because of differences between the architectures of PARC computers and laser printers, it was quite possible to display images on screen that could not be printed. ###### Message-ID: Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) From: halbert@bbn.com (Dan Halbert) Lines: 25 X-Trace: /Kw5eDNCAK1AFfOGsJbEQy8KWo+13cRGd6nRGucAS1reCdz8+gZV1rSTAwapEABpH15v5tXYj/US!y2ziReNAo7pYKUHarb5dqjkkxjS+d0Wi43K97tvalVaSOOkvYFo= X-Complaints-To: abuse@gtei.net X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly NNTP-Posting-Date: Wed, 07 Jul 1999 14:54:36 GMT Distribution: world Date: Wed, 07 Jul 1999 14:54:36 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.mathworks.com!cam-news-hub1.bbnplanet.com!news.gtei.net!burlma1-snr2!not-for-mail "Computer Structures: Readings and Examples", by Bell and Newell, published 1971 by McGraw Hill. This is an earlier version of "Computer Structures: Principles and Examples", by Sieworek, Bell, and Newell, published 1982, so you might look there too. (I don't have the latter book.) This book is a collection of papers on machine architecture. Section 4 contains three papers on "Processors based on a programming language". Two are paper designs (hardware never built). One is from 1958 and discusses hardware for the IPL-V language (a list processing language). A 1967 paper discusses the design of a machine to directly execute FORTRAN code. The third paper (1967) describes a microcode implementation of the ALGOL-like language EULER, running on an IBM 360/30. The EULER code is compiled into Reverse Polish. EULER includes run-time typing and list processing. As I think has already been mentioned, some old Burroughs machines were stack machines whose architecture was very closely tied to the ALGOL derivate that was the main programming language for those machines. Dan Halbert ###### From: timothy.mccaffrey@spam2filter.unisys.com.takethisoff (Tim McCaffrey) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 7 Jul 1999 17:59:02 GMT Organization: A series networking Lines: 15 Distribution: world Message-ID: <7m04h6$ilg$1@mail.pl.unisys.com> References: NNTP-Posting-Host: mccafftm.tr.unisys.com X-Newsreader: WinVN 0.99.9 (Released Version) (x86 32bit) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!isdnet!news.tvd.be!uunet!ams.uu.net!ffx.uu.net!bbnews1!bbnews1.unisys.com!plnews.pl.unisys.com!not-for-mail In article , halbert@bbn.com says... >> >As I think has already been mentioned, some old Burroughs machines were >stack machines whose architecture was very closely tied to the ALGOL >derivate that was the main programming language for those machines. > >Dan Halbert > > And they are still around, currently called Clearpath NX/LX. -- Tim McCaffrey NOT speaking for Unisys. ###### From: rpw3@rigden.engr.sgi.com (Rob Warnock) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 7 Jul 1999 09:43:17 GMT Organization: Silicon Graphics Inc., Mountain View, CA Lines: 27 Message-ID: <7lv7fl$6qaku@fido.engr.sgi.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> <7lu9ab$n0k@dfw-ixnews7.ix.netcom.com> NNTP-Posting-Host: rigden.engr.sgi.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!enews.sgi.com!fido.engr.sgi.com!rigden.engr.sgi.com!rpw3 Zalman Stern wrote: +--------------- | In comp.arch Greg Gritton wrote: | : - Xerox Alto and Dorado had microcode to execute Smalltalk bytecodes | | Speaking of which, wasn't the Alto semi-multithreaded as well? As in the | processor switched among some number of perhaps hardwired tasks to handle | I/O and graphics as well as executing the instruction set microcode. +--------------- Yup. IIRC, 16 microthreads. Each "DMA controller" (Ethernet, disk, gfx, etc.) was actually a microthread that "resumed" when an external data ready flag line went true (e.g., "Ethernet-receive-FIFO-not-empty"). This was efficient since the multi-threaded microcode engine was significantly faster than the memory system, so that doing DMA was going to stop normal (macro) instruction fetch *anyway* (due to busying the memory), so why not use the otherwise-idle ALU to run the DMA engines? Cute, hunh? -Rob ----- Rob Warnock, 8L-855 rpw3@sgi.com Applied Networking http://reality.sgi.com/rpw3/ Silicon Graphics, Inc. Phone: 650-933-1673 1600 Amphitheatre Pkwy. FAX: 650-933-0511 Mountain View, CA 94043 PP-ASEL-IA ###### From: abaum@pa.dec.com (Allen J. Baum) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Wed, 07 Jul 1999 16:46:35 -0700 Organization: Compaq Computer Lines: 26 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: althea.pa.dec.com X-Newsreader: MT-NewsWatcher 2.4.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!news1.digital.com!pa.dec.com!src.dec.com!abaum In article <37829F73.8B3EEF9F@intel.com>, Greg Gritton wrote: > To a large degree, the list of machines that directly > execute programming languages depends on how "directly" you mean. > > From the most direct to the least direct: > 1. Execute ASCII (or equivalent) directly > 2. Execute tokenized code directly .... > Some examples I am familiar with are: > (1) Direct ASCII > (2) Tokenized - If you count ROM, many old BASIC interpreters did this* The symbol machine was a 2; this might not make it really unusual, except ... it had no ROM. It really did directly execute the language in hardware. It also did directly compile the language in hardware. There was no compiler program. (you might, then, argue that this was really a 1, since there was no software that generated tokens....) ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 8 Jul 1999 00:03:48 GMT Organization: Netcom Lines: 9 Message-ID: <7m0pt4$g9m@dfw-ixnews9.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Wed Jul 07 7:03:48 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!ix.netcom.com!not-for-mail In comp.arch Allen J. Baum wrote: : it had no ROM. It really did directly execute the language in hardware. : It also did directly compile the language in hardware. There was : no compiler program. Was there an instruction that took a pointer to text and generated tokens into a buffer or some such? -Z- ###### From: jmfbahciv@aol.com Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 08 Jul 99 09:18:46 GMT Organization: UltraNet Communications, Inc. Lines: 36 Message-ID: <7m217d$8sq$3@autumn.news.rcn.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> X-Trace: cJICScFjRFCkwZ88ecI0Zv19aUceI78zTaJlviCi9Ag= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 8 Jul 1999 11:14:53 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!d1 In article , abaum@pa.dec.com (Allen J. Baum) wrote: >In article <37829F73.8B3EEF9F@intel.com>, Greg Gritton wrote: > >> To a large degree, the list of machines that directly >> execute programming languages depends on how "directly" you mean. >> >> From the most direct to the least direct: >> 1. Execute ASCII (or equivalent) directly >> 2. Execute tokenized code directly >..... > >> Some examples I am familiar with are: >> (1) Direct ASCII > >> (2) Tokenized > > - If you count ROM, many old BASIC interpreters did this* > >The symbol machine was a 2; >this might not make it really unusual, except ... > >it had no ROM. It really did directly execute the language in hardware. >It also did directly compile the language in hardware. There was >no compiler program. > >(you might, then, argue that this was really a 1, since there >was no software that generated tokens....) How many passes did it have to make? I'm think about resolving addresses of external calls and branching (or wasn't that allowed?). /BAH Subtract a hundred and four for e-mail. ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages ) Date: 08 Jul 1999 21:09:58 +0200 Organization: My own Private Self Lines: 55 Sender: neil@chonsp.franklin.ch Message-ID: <6uk8sb2c1l.fsf@chonsp.franklin.ch> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> <7lu9ab$n0k@dfw-ixnews7.ix.netcom.com> <7lv7fl$6qaku@fido.engr.sgi.com> X-Newsreader: Gnus v5.3/Emacs 19.34 rpw3@rigden.engr.sgi.com (Rob Warnock) writes: > > Zalman Stern wrote: > | > | Speaking of which, wasn't the Alto semi-multithreaded as well? As in the > | processor switched among some number of perhaps hardwired tasks to handle > | I/O and graphics as well as executing the instruction set microcode. > > Yup. IIRC, 16 microthreads. And 8 separate register sets, to which can be randomly assigned each thread. > Each "DMA controller" (Ethernet, disk, gfx, etc.) Video 1 reg set and 3 threads Disk 1 reg set and 2 threads Ethernet 1 reg set and 2 threads User program 1 reg set and 1 thread reserved 4 reg sets and 8 threads For G/D/E each 1 thread shoveled data, the rest implemented framing (video horiz and vert retrace, disk sectoring, ether frames). > was actually a microthread that "resumed" when an external data ready flag > line went true (e.g., "Ethernet-receive-FIFO-not-empty"). Actually it was an 16 line -> 4 bit priority encoder, which simply selected which of the 16 microcode instruction pointers to use for the next instruction fetch. Zero cycle thread switching that. > This was efficient > since the multi-threaded microcode engine was significantly faster than the > memory system, so that doing DMA was going to stop normal (macro) instruction > fetch *anyway* (due to busying the memory), so why not use the otherwise-idle > ALU to run the DMA engines? Cute, hunh? Elegant definitely. But video alone cost 2/3 of processor power. If you compare that with hardware DMA interleaved with processor memory access it looks less great. But there again Alto was intended as an research computer, not as an speed demon for numerical problems. And development time (only a handfull of engineers) and production cost (only a few thousand intended to make) were surely reduced. -- Neil Franklin, Nerd, Geek, Unix Wizzard and Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Computer: toy that speeds work, so you have more time to play with it ###### From: Ian Stirling Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 08 Jul 1999 20:23:35 GMT Distribution: world Message-ID: <931465415.13863.0.nnrp-04.9e98d142@news.demon.co.uk> References: <7m04h6$ilg$1@mail.pl.unisys.com> NNTP-Posting-Host: mauve.demon.co.uk X-NNTP-Posting-Host: mauve.demon.co.uk:158.152.209.66 X-Trace: news.demon.co.uk 931465415 nnrp-04:13863 NO-IDENT mauve.demon.co.uk:158.152.209.66 X-Complaints-To: abuse@demon.net User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (Linux/2.2.5 (i586)) Originator: root@mauve.demon.co.uk Lines: 13 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!news0.de.colt.net!colt.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!mauve.demon.co.uk!root Tim McCaffrey wrote: >In article , halbert@bbn.com says... >>> >>As I think has already been mentioned, some old Burroughs machines were >>stack machines whose architecture was very closely tied to the ALGOL >>derivate that was the main programming language for those machines. >> >>Dan Halbert >And they are still around, currently called Clearpath NX/LX. And the forth microprocessor, that I think was produced in low volume. ###### Message-ID: <37860DE2.D5A2DEA2@mitretek.org> Date: Fri, 09 Jul 1999 10:57:38 -0400 From: Chris Reedy Reply-To: creedy@mitretek.org X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7ldnmm$ctu$1@null.agames.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 206.241.50.62 X-Trace: 9 Jul 1999 09:55:21 -0500, 206.241.50.62 Lines: 28 X-Report: Report abuse to abuse@newsfeeds.com X-Abuse-Info: Please be sure to forward a copy of ALL headers, INCLUDING the body X-Abuse-Info2: Otherwise we will be unable to process your complaint properly Organization: Newsfeeds.com http://www.newsfeeds.com 73,000+ UNCENSORED Newsgroups. Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!netnews.com!news-feed.fnsi.net!feed.newsfeeds.com!newsfeeds.com!nntprelay.newsfeeds.com!newsfeeds.com!news.newsfeeds.com!newsfeeds.com!206.241.50.62 Mike Albaugh wrote: > > > : Of course, there's also Western Digital's chipset that directly > : executed UCSD P-code, but that's a little more than tokenization. > > Right. I'd love to hear of any such machines, but I haven't > run across any, and I've run across some seriously wierd machines... > I still own (It's been in a box in my basement for years) a P-Machine. It was an LSI-11 with the microcode modified to directly execute UCSD P-Code. The compiler did a direct conversion from Pascal to P-Code. Chris P.S. I would be willing to let it go to a good home. -- This is informal and not an official Mitretek Systems position. Dr. Christopher L. Reedy, Senior Principal Software Engineer Mitretek Systems M/S Z551, 7525 Colshire Drive, McLean, VA 22102-7400 Email: creedy@mitretek.org Phone: (703) 610-1615 FAX: (703) 610-1603 -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==---------- http://www.newsfeeds.com The Largest Usenet Servers in the World! ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==----- ###### From: Juergen Nickelsen Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 10 Jul 1999 15:05:32 +0200 Organization: [Posted via] Interactive Networx Lines: 16 Sender: nickel@goting.jn.berlin.snafu.de Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: n65-143.berlin.snafu.de X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!unlisys!news.snafu.de!goting.jn.berlin.snafu.de!nobody Greg Gritton writes: > 3. Execute a compiled form with a simple compiler > (examples include byte-codes, P-code, M-code, and JVM instructions) I don't think it makes a compiler simpler if its target machine is a virtual instead of a real one. Does it? If so, why? > - In 1988, a single transputer, running Occam (or C), could outperform > the 386 (its contemorary). In 1988 the transputer was an expensive high-end CPU. The 386 chip was already in the mass market. -- Juergen Nickelsen ###### From: ttk@for_mail_remove_this_and_fruit.larva.apple.shinma.org (TTK Ciar) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> Organization: Subtle, but there Lines: 17 Message-ID: NNTP-Posting-Host: 205.179.17.2 X-Trace: typ32b.nn.bcandid.com 931712179 205.179.17.2 (Sun, 11 Jul 1999 12:56:19 EDT) NNTP-Posting-Date: Sun, 11 Jul 1999 12:56:19 EDT Date: Sun, 11 Jul 1999 16:56:19 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!hub1.ispnews.com!typ32b.nn.bcandid.com.POSTED!not-for-mail In article , Juergen Nickelsen wrote: >Greg Gritton writes: > >> 3. Execute a compiled form with a simple compiler >> (examples include byte-codes, P-code, M-code, and JVM instructions) > >I don't think it makes a compiler simpler if its target machine is >a virtual instead of a real one. Does it? If so, why? It can. Your "soft" CPU can leave out the nasty bits -- delay slots, special-purpose registers, global flags, jump address length limitations, etc, all the things that can make writing a gcc back-end nontrivial. -- TTK ###### From: "Eric Hildum" Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Mon, 12 Jul 1999 19:18:34 -0700 Organization: Personal copy Lines: 19 Message-ID: <7me7ko$omn$1@bgtnsc01.worldnet.att.net> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> NNTP-Posting-Host: 12.72.88.193 Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: bgtnsc01.worldnet.att.net 931832280 25303 12.72.88.193 (13 Jul 1999 02:18:00 GMT) X-Complaints-To: abuse@worldnet.att.net NNTP-Posting-Date: 13 Jul 1999 02:18:00 GMT X-Newsreader: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn3feed!worldnet.att.net!wnmaster2!not-for-mail I have seen a lot of references to the "LSI-11" chip set; however, as I recall there were a number of implementations of the LSI-11 ISA. The original, which I think was a four IC set, and later ones such as the T-11 and F-11 (used in the PDP notebook computer prototype circa 1981.) To which one(s) are you all referring in the performance discussions? ---------- In article <7lg5oi$pl2$1@news-sj-2.cisco.com>, samiam@cisco.com (Scott A. spam-me-some-moore) wrote: > Performing a web lookup on that was not forthcoming with a date for > the microengine. The LSI-11 chipset is dated 1976, which probally > dates the Microengine to 1978, and the "performance" article I was > talking about was after the microengine was out and in use, > about 1979-1980, well within the life of the 68000. Pedantic mode > off. ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 13 Jul 1999 12:11:55 GMT Organization: Daedalus Consulting Lines: 44 Message-ID: <931867914.350969@estelle.paradise.net.nz> References: <7lassu$p2q$1@mail.pl.unisys.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> <7me7ko$omn$1@bgtnsc01.worldnet.att.net> NNTP-Posting-Host: estelle.paradise.net.nz X-Trace: titan.xtra.co.nz 931867915 5196285 203.96.152.5 (13 Jul 1999 12:11:55 GMT) X-Complaints-To: abuse@xtra.co.nz NNTP-Posting-Date: 13 Jul 1999 12:11:55 GMT Cache-Post-Path: estelle.paradise.net.nz!unknown@p16-cable.paradise.net.nz X-Cache: nntpcache 2.3.3b4 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.berkeley.edu!su-news-hub1.bbnplanet.com!lsanca1-snf1!news.gtei.net!news.netgate.net.nz!news.xtra.co.nz!don In article <7me7ko$omn$1@bgtnsc01.worldnet.att.net>, Eric Hildum wrote: >I have seen a lot of references to the "LSI-11" chip set; however, as I >recall there were a number of implementations of the LSI-11 ISA. The >original, which I think was a four IC set, and later ones such as the T-11 >and F-11 (used in the PDP notebook computer prototype circa 1981.) The terminology gets a little confusing. My 1980 Microcomputer Processor Handbook refers to the LSI-11, LSI-11/2 and LSI-11/23 boards (not chipsets), of which the first two are LSI-11 chipsets on different cards, and the /23 is an F-11 chipset. I've heard the term LSI-11/73 for the J-11 boards, but I don't think it was ever "official". On the other hand, the PDT-11 desription talks about the LSI-11 chipset, but the PDT doesn't use Qbus (aka "LSI-11 bus") boards, which is what the LSI-11 and LSI-11/2 CPU cards are. When talking chipsets rather than modules, the LSI-11 is the circa 1975 Western Digital developed four-carrier chipset, with really lousy performance, optional microm (for FIS or EIS) and no memory management. Generally, if someone refers to an LSI-11 without a qualifying /nn, they mean the LSI-11 chipset, or a board or system based around it. I've never heard of the T-11 being called an LSI-11, even though its capabilities more closely match the LSI-11 than the F-11 or J-11. Very roughly, the Qbus systems pan out around the four "micro-11" chipsts like this: Chipset Board System LSI-11 KD11-F (LSI-11) 11/03 KD11-H (LSI-11/2) 11/03 F-11 KDF11-A (LSI-11/23) 11/23 KDF11-B 11/23+ J-11 KDJ11-A 11/73 KDJ11-B 11/73, 11/83, 11/84 KDJ11-D 11/53 KDJ11-E 11/93, 11/94 T-11 KXT11 SBC-11/21 (Falcon) -- don ###### Message-ID: <378AF4E6.4D74B30C@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <7leggb$r8g$1@news-sj-3.cisco.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> <7me7ko$omn$1@bgtnsc01.worldnet.att.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 31 Date: Tue, 13 Jul 1999 12:12:24 GMT NNTP-Posting-Host: 198.232.144.27 X-Complaints-To: Abuse Role , We Care X-Trace: newshog.newsread.com 931867944 198.232.144.27 (Tue, 13 Jul 1999 08:12:24 EDT) NNTP-Posting-Date: Tue, 13 Jul 1999 08:12:24 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!howland.erols.net!news-xfer.netaxs.com.MISMATCH!news-xfer.newsread.com!netaxs.com!newsread.com!POSTED.newshog.newsread.com!not-for-mail Eric Hildum wrote: > > I have seen a lot of references to the "LSI-11" chip set; however, as I > recall there were a number of implementations of the LSI-11 ISA. Not so much the "LSI-11 ISA", but "a LSI implementation of the PDP-11 ISA", IMHO. > The > original, which I think was a four IC set, and later ones such as the T-11 > and F-11 (used in the PDP notebook computer prototype circa 1981.) And a few years after that, the J-11, and today, several custom VLSI implementations giving even greater PDP-11 performance (see for example http://www.mentec.com/ ). The F11 found its way into the PDP-11/24, and the J11 into the PDP-11/84 and -94, computers that were never marketed as "LSI-11's". The "LSI" moniker was generally only used in describing the earlier Q-bus implementations. (Marketing's effect on name choice, of course.) > To which one(s) are you all referring in the performance discussions? We're generally talking about the "original LSI-11" a chipset by Western Digital with rather configurable microcode that was used in the DEC LSI-11/03. AFAIK this is the only one that was also pressed into service with custom microcode for running the UCSD P-system natively. Tim. ###### Message-ID: <378B1254.3F66EAEB@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <377AA378.72CC66A9@trailing-edge.com> <7lg5oi$pl2$1@news-sj-2.cisco.com> <7me7ko$omn$1@bgtnsc01.worldnet.att.net> <931867914.350969@estelle.paradise.net.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 16 Date: Tue, 13 Jul 1999 14:17:59 GMT NNTP-Posting-Host: 198.232.144.27 X-Complaints-To: Abuse Role , We Care X-Trace: monger.newsread.com 931875479 198.232.144.27 (Tue, 13 Jul 1999 10:17:59 EDT) NNTP-Posting-Date: Tue, 13 Jul 1999 10:17:59 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!newspeer1.nac.net!yellow.newsread.com!netaxs.com!newsread.com!POSTED.monger.newsread.com!not-for-mail Don Stokes wrote: > The terminology gets a little confusing. I'll agree with you there! The label on the box and the name used for the chipset aren't necessarily strongly related. Marketing! > F-11 KDF11-A (LSI-11/23) 11/23 > KDF11-B 11/23+ When the KDF11-B was in a BA[1]23 box, it was a "Micro PDP-11/23+". Otherwise it wasn't :-). There's also the KDF11-CA (Professional 325), KDF11-CB (Professional 350), and KDF11-UA (used in the Unibus PDP-11/24.) Tim. ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 12 Jul 1999 07:39:17 GMT Organization: Netcom Lines: 17 Message-ID: <7mc635$28@dfw-ixnews8.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Mon Jul 12 2:39:17 AM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!ix.netcom.com!not-for-mail In comp.arch TTK Ciar wrote: : It can. Your "soft" CPU can leave out the nasty bits -- delay : slots, special-purpose registers, global flags, jump address length : limitations, etc, all the things that can make writing a gcc back-end : nontrivial. As to delay slots and jump address length limits, you can generally just ignore them too. Nop the delays slots and always use a jump sequence that can do the largest amount. Oh, you care about performance? Well then the soft CPU approach isn't gonna be any better. (In some environments, either the assembler or a postprocessor will do the instruction scheduling necessary to handle delay slots and short jump optimization.) -Z- ###### From: Jan Vorbrueggen Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 12 Jul 1999 08:58:51 +0200 Organization: Institut fuer Neuroinformatik, Ruhr-Universitaet Bochum, Germany Lines: 10 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> NNTP-Posting-Host: thalia.neuroinformatik.ruhr-uni-bochum.de X-Trace: sunu789.rz.ruhr-uni-bochum.de 931762571 5315 134.147.176.76 (12 Jul 1999 06:56:11 GMT) NNTP-Posting-Date: 12 Jul 1999 06:56:11 GMT X-Newsreader: Gnus v5.3/Emacs 19.33 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-stuttgart.de!news.ruhr-uni-bochum.de!not-for-mail Juergen Nickelsen writes: > In 1988 the transputer was an expensive high-end CPU. The 386 chip > was already in the mass market. The T800/T400 expensive? Especially in a useable system? No way. The reasons for its failure are others. Jan ###### Date: Mon, 12 Jul 1999 09:06:07 +0100 From: christian.bau@isltd.insignia.com (Christian Bau) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> Organization: Insignia Solutions Cache-Post-Path: proxy0.isltd.insignia.com!unknown@christian-mac.isltd.insignia.com NNTP-Posting-Host: proxy0.isltd.insignia.com X-Trace: 12 Jul 1999 09:05:27 GMT, proxy0.isltd.insignia.com Lines: 19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!news0.de.colt.net!colt.net!ayres.ftech.net!news.ftech.net!news.lattis.xara.net!psiuk-f4!psiuk-p4!uknet!psiuk-n!nnrp1.news.uk.psi.net!christian-mac.isltd.insignia.com!user In article , Juergen Nickelsen wrote: > Greg Gritton writes: > > > 3. Execute a compiled form with a simple compiler > > (examples include byte-codes, P-code, M-code, and JVM instructions) > > I don't think it makes a compiler simpler if its target machine is > a virtual instead of a real one. Does it? If so, why? Absolutely. Consider that the whole UCSD Pascal compiler was about 6000 lines of code. All the code generation was done by exactly the same routines that analysed the syntax. No optimisation because on a p-machine there was not much you could optimise anyway (stack, no registers). For Java: Look at the description of "finally" in the language and think about how you would implement that on any normal processor. In J-code, it is trivial. ###### Message-ID: <378A1D6C.B6B9188F@jps.net> Date: Mon, 12 Jul 1999 09:53:00 -0700 From: Dennis Yelle X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <37829F73.8B3EEF9F@intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 209.239.196.156 X-Original-NNTP-Posting-Host: 209.239.196.156 X-Trace: 12 Jul 1999 17:33:22 -0700, 209.239.196.156 Lines: 32 X-Original-NNTP-Posting-Host: 209.63.224.240 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!paloalto-snf1.gtei.net!news.gtei.net!newsfeed.stanford.edu!remarQ73!supernews.com!remarQ.com!nuq-peer.news.verio.net!newsfeed.easynews.com!easynews!news-west.eli.net!news1.jps.net!209.239.196.156 Christian Bau wrote: > > In article , Juergen Nickelsen > wrote: > > > Greg Gritton writes: > > > > > 3. Execute a compiled form with a simple compiler > > > (examples include byte-codes, P-code, M-code, and JVM instructions) > > > > I don't think it makes a compiler simpler if its target machine is > > a virtual instead of a real one. Does it? If so, why? > > Absolutely. Consider that the whole UCSD Pascal compiler was about 6000 > lines of code. All the code generation was done by exactly the same > routines that analysed the syntax. No optimisation because on a p-machine > there was not much you could optimise anyway (stack, no registers). > > For Java: Look at the description of "finally" in the language and think > about how you would implement that on any normal processor. In J-code, it > is trivial. It is just as hard (or easy) as the catch(...) { } from C++. In other words, it is only hard until you do it the first time. After that it is just, "Yes, we know how to do that." Dennis Yelle -- Want to get paid for using the internet? If so, go to: http://alladvantage.com/go.asp?refid=BAL536 ###### From: mj@isy.liu.se (Michael Josefsson) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Tue, 20 Jul 1999 09:32:26 CET Organization: LiTH / Dept of EE Lines: 51 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: lagrange.isy.liu.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: Trumpet for Windows [Version 1.0 Rev B] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!fu-berlin.de!newsfeed.tli.de!newsfeed1.swip.net!swipnet!newnews.hk-r.se!news.ifm.liu.se!lagrange.isy.liu.se!mj In article Juergen Nickelsen writes: >Path: >news.ifm.liu.se!news.lth.se!feed2.news.luth.se!luth.se!uio.no!newsfeed.nacamar.d >e!unlisys!news.snafu.de!goting.jn.berlin.snafu.de!nobody >From: Juergen Nickelsen >Newsgroups: alt.folklore.computers,comp.arch >Subject: Re: CPU's directly executing HLL's (was Re: Which programming >languages) >Date: 01 Jul 1999 21:46:00 +0200 >Organization: [Posted via] Interactive Networx >Lines: 17 >Sender: nickel@goting.jn.berlin.snafu.de >Message-ID: >References: <7lassu$p2q$1@mail.pl.unisys.com> ><7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> ><377A0DF8.1E1FAFE9@trailing-edge.com> >NNTP-Posting-Host: n34-121.berlin.snafu.de >X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" >In-Reply-To: Tim Shoppa's message of "Wed, 30 Jun 1999 16:30:51 GMT" >Xref: news.ifm.liu.se alt.folklore.computers:201006 comp.arch:93684 >Tim Shoppa writes: >> There's the LISP Engine, but I don't know if it internally stored >> the code in human-readable or tokenized form. >As far as I know, the Lisp machines of MIT ancestry (LMI, Symbolics, >TI Explorer(?)) have a highly optimizing compiler, only the hardware >is tuned to execute the operations most frequently Lisp very fast -- >consing cells, accessing elements of a cell, calling functions, etc. >Closer to the execution of ASCII text would be the Novix Forth chip, >which, IIRC, executes several basic Forth operators after little (if >at all) more than tokenization. But surely others can say more about >it. (Communa?) The Novix used primitive Forth words as its assembler. Some 10-15 were supplied all else was done through small software routines (things like comparisons, control structures, store/fetch of anything else than 16-bit varialbles. It had three separate memories externally: parameter stack, return stack and program memory. This minimized the I/O bottleneck. IIRC, it ran at 4 MHz - normal at the time, but Forth made programs quick. My reference is "Footsteps in an empty valley" C.H. Ting, Offete Enterprises, 1987 /Micke >-- >Juergen Nickelsen ###### From: mj@isy.liu.se (Michael Josefsson) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Tue, 20 Jul 1999 09:35:09 CET Organization: LiTH / Dept of EE Lines: 49 Message-ID: References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> NNTP-Posting-Host: lagrange.isy.liu.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: Trumpet for Windows [Version 1.0 Rev B] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.swip.net!swipnet!newnews.hk-r.se!news.ifm.liu.se!lagrange.isy.liu.se!mj In article Juergen Nickelsen writes: >Path: >news.ifm.liu.se!news.lth.se!feed2.news.luth.se!luth.se!uio.no!newsfeed.nacamar.d >e!unlisys!news.snafu.de!goting.jn.berlin.snafu.de!nobody >From: Juergen Nickelsen >Newsgroups: alt.folklore.computers,comp.arch >Subject: Re: CPU's directly executing HLL's (was Re: Which programming >languages) >Date: 01 Jul 1999 21:46:00 +0200 >Organization: [Posted via] Interactive Networx >Lines: 17 >Sender: nickel@goting.jn.berlin.snafu.de >Message-ID: >References: <7lassu$p2q$1@mail.pl.unisys.com> ><7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> ><377A0DF8.1E1FAFE9@trailing-edge.com> >NNTP-Posting-Host: n34-121.berlin.snafu.de >X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald" >In-Reply-To: Tim Shoppa's message of "Wed, 30 Jun 1999 16:30:51 GMT" >Xref: news.ifm.liu.se alt.folklore.computers:201006 comp.arch:93684 >Tim Shoppa writes: >> There's the LISP Engine, but I don't know if it internally stored >> the code in human-readable or tokenized form. >As far as I know, the Lisp machines of MIT ancestry (LMI, Symbolics, >TI Explorer(?)) have a highly optimizing compiler, only the hardware >is tuned to execute the operations most frequently Lisp very fast -- >consing cells, accessing elements of a cell, calling functions, etc. >Closer to the execution of ASCII text would be the Novix Forth chip, >which, IIRC, executes several basic Forth operators after little (if >at all) more than tokenization. But surely others can say more about >it. (Communa?) And then there is the Harris RTX2000 line. Now discontinued except for radiation hardened devices to be used in space modules. Ran at 10 MHz, but was designed to be able to perform up to five instructions (Forth primitives) in one clock. Also used a 16x16->32 muliplier in Si. I actually have one of those running happily here. /Micke >-- >Juergen Nickelsen ###### Newsgroups: alt.folklore.computers,comp.arch From: dp@world.std.com (Jeff DelPapa) Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Message-ID: Date: Tue, 20 Jul 1999 18:18:50 GMT References: <7lassu$p2q$1@mail.pl.unisys.com> <3794b742@newsread3.dircon.co.uk> Organization: Chaos and Confusion Lines: 39 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!news.idt.net!peerfeed.news.psi.net!uunet!ffx.uu.net!world!dp In article <3794b742@newsread3.dircon.co.uk>, Ian Kemmish wrote: >In article , mj@isy.liu.se says... > >>>Closer to the execution of ASCII text would be the Novix Forth chip, >>>which, IIRC, executes several basic Forth operators after little (if >>>at all) more than tokenization. But surely others can say more about >>>it. (Communa?) > >I've dipped into this thread from time to time. No-one seemed to have >mentioned the problem of designing an adder which works with ASCII text. It >seems a comptuer which executed text *directly* would have to be able to cope >with constants before its designers could be allowed to worry about >variables:-) > There have been a number of machines that have adders that work on character data. When all you are going to do with a value is add it once to a total, its a whole lot faster to not bother with any conversion. All it takes is a masking stage ahead of your packed BCD serial adder logic. Read the sucker in, make one pass over it, and move on to the next value. CPU touches each byte only once, and performs a single add per digit. To convert a decimal string to binary, you have to mask, multiply and add for each digit. Its expensive. (binary multiply doesn't usually come with a "mask one of the operators" option, so you have to have to load and mask before you multiply) Pack and unpack instructions were known members of commercial instruction sets. At least one machine had instructions that added unpacked decimal to packed decimal values. If you were going to do a few operations on a value, or keep lots of them around, it was worth the trouble to pack them. You didn't convert to pure binary, or floating point, never mind the time, the applications didn't want to drop any pennies. Variable length decimal was THE way to go. (some of the machines with this feature, didn't have the concept of a binary word, everything was a variable length feild to them) -dp- ###### From: Zalman Stern Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 20 Jul 1999 18:33:34 GMT Organization: Netcom Lines: 14 Message-ID: <7n2fdu$jrd@dfw-ixnews15.ix.netcom.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <3794b742@newsread3.dircon.co.uk> NNTP-Posting-Host: netcom15.netcom.com X-NETCOM-Date: Tue Jul 20 1:33:34 PM CDT 1999 NNTP-Posting-User: zalman User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!howland.erols.net!ix.netcom.com!not-for-mail In comp.arch Ian Kemmish wrote: : I'd love to see the ALU that could cope with that:-) If you'd just drink the high level execution kool aid, then you'd have no problem with a multi-layered pipeline structure where one of the outer layers has a lexer stage and a parser stage. After all, those "compiler choads" aren't to be trusted and there isn't anything that can be done in software that can't be done better in hardware. Good kool aid man! The whole thread is sort of like discussing mating a pig and an elephant. It works far better as a South Park episode than as a PhD thesis in biology. -Z- ###### Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) From: ian@five-d.com (Ian Kemmish) Organization: At home with Ian X-Newsreader: WinVN 0.99.5 References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset=ISO-8859-1 X-Original-NNTP-Posting-Host: 194.112.47.5 Message-ID: <3794b742@newsread3.dircon.co.uk> Date: 20 Jul 1999 18:52:02 +0100 X-Original-NNTP-Posting-Host: 194.112.32.19 Lines: 28 NNTP-Posting-Host: newsread3.dircon.co.uk X-Trace: reader.news.dircon.net 932493123 170 194.112.32.19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.icl.net!ayres.ftech.net!news.ftech.net!peer1.news.dircon.net!peer2.news.dircon.net!reader.news.dircon.net!not-for-mail In article , mj@isy.liu.se says... >>Closer to the execution of ASCII text would be the Novix Forth chip, >>which, IIRC, executes several basic Forth operators after little (if >>at all) more than tokenization. But surely others can say more about >>it. (Communa?) I've dipped into this thread from time to time. No-one seemed to have mentioned the problem of designing an adder which works with ASCII text. It seems a comptuer which executed text *directly* would have to be able to cope with constants before its designers could be allowed to worry about variables:-) Westerners have invented quite enough problems (for example, does a comma mean `decimal point' or `thousands separator' today?), but consider the Japanese edition of such a machine - suppose you wanted to calculate 2 + 2 + 2 + 2. Lets keep it simple assume that we intend only to support Shift-JIS encoding. Except that the first two was expressed in fixed pitch Roman text, the second in proportional Roman, the third in Hiragan and the fourth in Katakana. I'd love to see the ALU that could cope with that:-) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ, UK ian@five-d.com Tel: +44 1767 601 361 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Behind every successful organisation stands one person who knows the secret of how to keep the managers away from anything truly important. ###### From: euphrates@bigwig.net Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 22 Jul 1999 19:38:58 GMT Organization: Cable Internet (post doesn't reflect views of Cable Internet) Lines: 29 Message-ID: <37977352.0@news2> References: NNTP-Posting-Host: news2.cluster1.telinco.net X-Trace: news1.cableinet.co.uk 932668849 25180 212.1.128.155 (22 Jul 1999 18:40:49 GMT) X-Complaints-To: abuse@cableinet.net NNTP-Posting-Date: 22 Jul 1999 18:40:49 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!iol.ie!colt.net!newspeer.clara.net!news.clara.net!newsfeed.icl.net!easynet-tele!easynet.net!news5.cableinet.net!cableinet-uk!news1.cableinet.co.uk!news2!ppp-3-44.cvx5.telinco.net On 1999-07-20 mj@isy.liu.se(MichaelJosefsson) said: :The Novix used primitive Forth words as its assembler. Some 10-15 :were supplied all else was done through small software routines :(things like comparisons, control structures, store/fetch of :anything else than 16-bit varialbles. It had three separate :memories externally: parameter stack, return stack and program :memory. This minimized the I/O bottleneck. IIRC, it ran at 4 MHz - :normal at the time, but Forth made programs quick. In another post you mention the Harris RTX2001. This was actually pretty much a direct descendant of the Novix NC4000 (an NC6000 was planned, but was still 16 bit and used segmented memory). One bit of the instruction word, the MSB, controlled whether the word was interpreted as a 15-bit relative call or a 15-bit wide word of (essentially) microcode. Within those 15 bits, you could pretty much code what you liked, up to a theoretical maximum of about 7 bits. One of those bits was a return bit, which gave you free returns from subroutines. Basically it was a threaded code interpreter in hardware... Moore has designed a couple of microprocessors since (http://www.ptsc.com/, http://www.ultratechnology.com/f21.html) and they have tended to look much more like engines for direct execution of Forth than machines for direct execution of threaded code; a few Forth primitives are hardwired and programs composed from these, rather than rolling your own microcode. -- Communa -- you know soft spoken changes nothing ###### From: Digital.Magic@cadvision.com (John W Hall) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: Thu, 22 Jul 1999 23:13:25 GMT Message-ID: <3797a49a.73682058@news.cadvision.com> References: <37977352.0@news2> X-Newsreader: Forte Free Agent 1.11/32.235 NNTP-Posting-Host: 207.148.140.154 X-NNTP-Posting-Host: 207.148.140.154 X-Trace: 22 Jul 1999 17:13:51 -0700, 207.148.140.154 Organization: CADVision Development Corporation (http://www.cadvision.com/) Lines: 8 X-NNTP-Posting-Host: 204.50.1.43 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!lucky.medicusnet.de!news.csl-gmbh.net!news-fra.pop.de!newsfeed.nacamar.de!europa.netcrusader.net!207.114.4.11!nntp.abs.net!nntp.cadvision.com!news.cadvision.com!207.148.140.154 During my (too short) time at Hursley during my IBM career, I heard that someone had punched up microcode (there were copper traces on Mylar sheets, which were stacked and then ferrite cores assembled through them. The traces went through or past the cores depending on where holes were punched to cut the traces) that made one of the early small S/360 do APL as its native language. It was reputedly so blazing fast that he was instructed to stop and never reveal what he had done. ###### From: Greg Pfister Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: Fri, 23 Jul 1999 15:05:55 -0400 Organization: IBM Lines: 34 Message-ID: <3798BD13.7CB6B55C@us.ibm.com> References: <37977352.0@news2> <3797a49a.73682058@news.cadvision.com> NNTP-Posting-Host: pfister.austin.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!howland.erols.net!portc02.blue.aol.com!nyd.news.ans.net!abq.news.ans.net!news.chips.ibm.com!newsfeed.btv.ibm.com!rtpnews.raleigh.ibm.com!not-for-mail John W Hall wrote: > > During my (too short) time at Hursley during my IBM career, I heard > that someone had punched up microcode (there were copper traces on > Mylar sheets, which were stacked and then ferrite cores assembled > through them. The traces went through or past the cores depending on > where holes were punched to cut the traces) that made one of the early > small S/360 do APL as its native language. It was reputedly so blazing > fast that he was instructed to stop and never reveal what he had done. I don't know about ferrite cores on Mylar sheets; I'm not even familiar with any such technology, but it might have existed. However, there definitely was a nonstandard (but available to customers) microcode load for the 360/145 - which kept "microcode" in main memory - that added the instruction "interpret APL program." It was definitely *not* a case of "never reveal what was done". It was available to customers. I've no idea how many used it. It was indeed blazingly fast for its time. I used it, and can testify that it beat everything in sight until the next generation of systems came out. (Which has been an underlying problem with all such efforts.) (Well, it beat everything in my sight at the time - 360s models 155 and 165. For APL. Not other things. Can't testify about other APL implementations.) Timeframe: 1974. Greg Pfister ###### From: glass2@glass2.lexington.ibm.com Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: 23 Jul 1999 23:09:05 GMT Organization: IBM Austin Lines: 48 Message-ID: <7nasmh$12u0$1@ausnews.austin.ibm.com> References: <37977352.0@news2> <3797a49a.73682058@news.cadvision.com> <3798BD13.7CB6B55C@us.ibm.com> Reply-To: wa4qal@vnet.ibm.net NNTP-Posting-Host: glass2.cv.lexington.ibm.com X-Newsreader: IBM NewsReader/2 2.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!news0.de.colt.net!blackbush.xlink.net!howland.erols.net!newsfeed.fast.net!uunet!ffx.uu.net!an02.austin.ibm.com!ausnews.austin.ibm.com!not-for-mail In <3798BD13.7CB6B55C@us.ibm.com>, Greg Pfister writes: >John W Hall wrote: >> >> During my (too short) time at Hursley during my IBM career, I heard >> that someone had punched up microcode (there were copper traces on >> Mylar sheets, which were stacked and then ferrite cores assembled >> through them. The traces went through or past the cores depending on >> where holes were punched to cut the traces) that made one of the early >> small S/360 do APL as its native language. It was reputedly so blazing >> fast that he was instructed to stop and never reveal what he had done. > >I don't know about ferrite cores on Mylar sheets; I'm not even >familiar with any such technology, but it might have existed. > >However, there definitely was a nonstandard (but available to >customers) microcode load for the 360/145 - which kept >"microcode" in main memory - that added the instruction >"interpret APL program." > >It was definitely *not* a case of "never reveal what was done". >It was available to customers. I've no idea how many used it. > >It was indeed blazingly fast for its time. I used it, and can >testify that it beat everything in sight until the next >generation of systems came out. (Which has been an underlying >problem with all such efforts.) > >(Well, it beat everything in my sight at the time - 360s models >155 and 165. For APL. Not other things. Can't testify about other >APL implementations.) > >Timeframe: 1974. > >Greg Pfister > I believe he's referring to TROS, which was one of the technologies used for storing the microcode in some of the S/360 machines. The other technology used CCROS and was capacitive. I can't comment on the APL issue, but wasn't it the 5100 that ran APL natively, and wasn't it based (loosely?) on the S/360 architecture? Dave P.S. Standard Disclaimer: I work for them, but I don't speak for them. ###### From: Greg Pfister Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: Sat, 24 Jul 1999 18:12:10 -0400 Organization: IBM Lines: 26 Message-ID: <379A3A3A.CBCDF565@us.ibm.com> References: <37977352.0@news2> <3797a49a.73682058@news.cadvision.com> <3798BD13.7CB6B55C@us.ibm.com> <7nasmh$12u0$1@ausnews.austin.ibm.com> NNTP-Posting-Host: lig32-226-52-40.us.lig-dial.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!news-out.cwix.com!newsfeed.cwix.com!169.132.11.200!news.idt.net!nyd.news.ans.net!abq.news.ans.net!news.chips.ibm.com!newsfeed.btv.ibm.com!rtpnews.raleigh.ibm.com!not-for-mail glass2@glass2.lexington.ibm.com wrote: [snip] > I believe he's referring to TROS, which was one of the technologies > used for storing the microcode in some of the S/360 machines. The > other technology used CCROS and was capacitive. Could definitely be. Somebody commented to me offline that punches in stuff printed on Mylar was used for microcode in channel controllers, for example. > I can't comment on the APL issue, but wasn't it the 5100 that > ran APL natively, and wasn't it based (loosely?) on the S/360 > architecture? The 5100 was an early "personal computer" that fit on a desktop, sometime in the early 80s. It only ran APL, but far from native or direct execution. It ran an S/390 interpreter that executed the (official) S/390 APL interpreter. It was not a speed demon. The 370/145 I was speaking of did not fit on a desktop and was about 10 years earlier. Greg Pfister ###### Newsgroups: alt.folklore.computers From: jsaum@world.std.com (Jim Saum) Subject: Re: CPU's directly executing HLL's (was Which programming languages) Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Sun, 25 Jul 1999 09:59:35 GMT References: <37977352.0@news2> <3797a49a.73682058@news.cadvision.com> <3798BD13.7CB6B55C@us.ibm.com> <7nasmh$12u0$1@ausnews.austin.ibm.com> NNTP-Posting-Host: world.std.com Organization: Software Tool & Die, Brookline MA X-Newsreader: MT-NewsWatcher 2.4.4 Lines: 13 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news.new-york.net!uunet!ffx.uu.net!world!jsaum In article <7nasmh$12u0$1@ausnews.austin.ibm.com>, wa4qal@vnet.ibm.net wrote: >I believe he's referring to TROS, which was one of the technologies >used for storing the microcode in some of the S/360 machines. The >other technology used CCROS and was capacitive. The 360/30 used CCROS (Card Capacitor Read-Only Store, shaped and punched like punch cards). The 40 used TROS (Transformer Read-Only Store, flexible strips of mylar tape punched with holes of two different sizes). The 50, 65, and 85 used BCROS (Balanced Capacitor Read-Only Store). - Jim Saum ###### From: Pete Fenelon Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Newsgroups: alt.folklore.computers,comp.arch References: <7lassu$p2q$1@mail.pl.unisys.com> <7lccq8$tv$1@mermaid.ucc.gu.uwa.edu.au> <7ld5uj$2h2$4@autumn.news.rcn.net> <377A0DF8.1E1FAFE9@trailing-edge.com> <3794b742@newsread3.dircon.co.uk> User-Agent: tin/pre-1.4-19990216 ("Styrofoam") (UNIX) (Linux/2.0.36 (i586)) Date: Sun, 25 Jul 1999 11:18:41 +0100 Message-ID: <1aoen7.6m.ln@petefenelon.screaming.net> Lines: 18 NNTP-Posting-Host: man-207.dialup.zetnet.co.uk X-Trace: news.zetnet.co.uk 932898506 156 news@194.247.43.8 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!iol.ie!colt.net!newspeer.clara.net!news.clara.net!peer.news.zetnet.net!master.news.zetnet.net!not-for-mail In alt.folklore.computers Ian Kemmish wrote: > I've dipped into this thread from time to time. No-one seemed to have > mentioned the problem of designing an adder which works with ASCII text. It > seems a comptuer which executed text *directly* would have to be able to cope > with constants before its designers could be allowed to worry about > variables:-) hmmmm. Some of the early "FPAs" for microprocessors were actually calculator chips -- they were 'programmed' by sending the appopriate keypresses to them and values were read back by reading the display outputs... I think the AMD 9511 tended to be used this way (certainly it was an early FPA that I've seen fitted to 8085-based systems like the DAI... not sure if that was one of the chips that worked that way). Anyway... isn't that *vaguely* close to the topic? :) pete -- pete@fenelon.com "there's no room for enigmas in built-up areas" (HMHB) ###### Newsgroups: alt.folklore.computers,comp.arch From: ehrice@his.com (Edward Rice) Subject: Re: CPU's directly executing HLL's (was Which programming languages) Message-ID: Organization: NDS Date: Sun, 25 Jul 1999 23:27:53 -0400 References: <37977352.0@news2> <3797a49a.73682058@news.cadvision.com> <3798BD13.7CB6B55C@us.ibm.com> <7nasmh$12u0$1@ausnews.austin.ibm.com> <379A3A3A.CBCDF565@us.ibm.com> NNTP-Posting-Host: pm9-173.his.com Lines: 65 X-Authenticated-User: ehrice Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!iol.ie!colt.net!newsfeed.icl.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!remarQ-easT!supernews.com!remarQ.com!news.lightlink.com!news4.his.com!user In article <3797a49a.73682058@news.cadvision.com>, Digital.Magic@cadvision.com (John W Hall) wrote: > Subject: Re: CPU's directly executing HLL's (was Which programming languages) > From: John W Hall > Organization: CADVision Development Corporation (http://www.cadvision.com/) > Date: Thu, 22 Jul 1999 23:13:25 GMT > Newsgroups: alt.folklore.computers,comp.arch > > During my (too short) time at Hursley during my IBM career, I heard > that someone had punched up microcode (there were copper traces on > Mylar sheets, which were stacked and then ferrite cores assembled > through them. The traces went through or past the cores depending on > where holes were punched to cut the traces) that made one of the early > small S/360 do APL as its native language. It was reputedly so blazing > fast that he was instructed to stop and never reveal what he had done. In article <379A3A3A.CBCDF565@us.ibm.com>, Greg Pfister wrote: > glass2@glass2.lexington.ibm.com wrote: > [snip] > > I believe he's referring to TROS, which was one of the technologies > > used for storing the microcode in some of the S/360 machines. The > > other technology used CCROS and was capacitive. > > Could definitely be. Somebody commented to me offline that > punches in stuff printed on Mylar was used for microcode in > channel controllers, for example. The description sounds right for TROS or CROS (the one I remember personally). The folklore part arises in the "was so blindingly fast they told him to drop the project." IBM did what was described, but so did IBM customers. IBM never released their various microcode "upgrades" as products -- it is true that customers never saw direct advantages from them. (Long term, they may have shown up in improved microcode for later models.) There ensued a furor over whether, if the customers did this and ran the machine this way, IBM would then be held responsible for "problems that might come up." From the customer's point of view, if they restored the capacitive read-only storage cards to the original state and turned the machine over to IBM Field Engineering, then it ought to get fixed since it was rented and no permanent changes had been applied. From IBM's point of view, nobody knew what ungodly things might happen if the customer opened the case the computer was sheathed in, EVEN TO PAINT IT!, and if that happened, all bets were off and IBM reserved the right to charge the customer for destroying the machine and certainly could not guarantee that it would ever be fixed. Reading between the lines, there was also a strong subtext of "SO DON'T DO THAT!". Thing is, even simply for speeding the machines up so they ran the IBM instruction set faster, the customer microcode often outperformed what IBM distributed, and this would tend to undercut upgrades to achieve better performance. Long-term, the solution was to make IBM sell machines rather than rent them out, and to "encourage" IBM to produce decent microcode and machines that were price-competitive and performance-competitive. Eventually (it took a long time) they did. ###### Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) References: <7lassu$p2q$1@mail.pl.unisys.com> <3794b742@newsread3.dircon.co.uk> Organization: Wizvax Communications, LLC From: multics@wizvax.wizvax.net (Richard Shetron) NNTP-Posting-Host: wizvax.wizvax.net Message-ID: <379b99ed.0@news.wizvax.net> Date: 25 Jul 1999 19:12:45 -0500 X-Trace: 25 Jul 1999 19:12:45 -0500, wizvax.wizvax.net Lines: 58 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-han1.dfn.de!news-koe1.dfn.de!do.de.uu.net!newsfeed.tli.de!newspeer.monmouth.com!newsfeed.wizvax.net!news.wizvax.net!wizvax.wizvax.net!multics The WANG 2200 executed WANG 2200 BASIC in hardware with an excape mechanism to add extra instructions later via firmware load at boot time. If there was anything other then 2200BASIC, I was never aware of it. I was aware of some talk about other languages, but I never saw anything done. The CISC hardware instruction unit (required on Multics, optional on GCOS) on the Honeywell Multics 6180 (later Level 68) had an instruction format (simplified here and possibly not 100% correct due to faulty memory, it's been over 20 years since I last looked at manuals): the following formats for some opcodes: desc1=desc1 opcode desc2 desc1=desc2 desc3 opcode opcode desc1 desc1 desc2 desc2 desc3 descriptors could be any of the follwoing types and conversions would be done to do the operation specified by the opcode: fixed bin (multiple precisions) float bin (short or long) float decimal (up to 63 digits) fixed decimal (not sure of the limit) ascii text (a number in an ascii text field) additional types I don't remember for add, subtract, multiply, and divide, and descripton could be for any of the types above so the following statements could be done by one hardware instruction: dcl a fixed bin, b float bin, c char(20); a=b+c; c=a+b; b=a/c; as long as c contined a legal number, no error would result. In article <3794b742@newsread3.dircon.co.uk>, Ian Kemmish wrote: >In article , mj@isy.liu.se says... > >>>Closer to the execution of ASCII text would be the Novix Forth chip, >>>which, IIRC, executes several basic Forth operators after little (if >>>at all) more than tokenization. But surely others can say more about >>>it. (Communa?) > >I've dipped into this thread from time to time. No-one seemed to have >mentioned the problem of designing an adder which works with ASCII text. It >seems a comptuer which executed text *directly* would have to be able to cope >with constants before its designers could be allowed to worry about >variables:-) [snip] ###### Sender: lynn@LYNNPC Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Which programming languages) References: <37977352.0@news2> <3797a49a.73682058@news.cadvision.com> Reply-To: Anne & Lynn Wheeler From: Anne & Lynn Wheeler Message-ID: Organization: Wheeler&Wheeler Lines: 11 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jul 1999 17:09:38 GMT NNTP-Posting-Host: 209.63.28.138 X-Complaints-To: support@adcomsys.net X-Trace: news-west.eli.net 933008978 209.63.28.138 (Mon, 26 Jul 1999 11:09:38 MDT) NNTP-Posting-Date: Mon, 26 Jul 1999 11:09:38 MDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-fra1.dfn.de!news-koe1.dfn.de!do.de.uu.net!uunet!ams.uu.net!ffx.uu.net!news-west.eli.net!not-for-mail Palo Alto Science Center did the 370/145 APL microcode for APL/CMS ... speeded up APL execution by factor of 10* or so .... would give 370/145 APL better performance than 370/168 APL (vague recollection that it was done by Randy Scarboro) -- -- Anne & Lynn Wheeler | lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn ###### From: peter@baileynm.com (Peter da Silva) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: 26 Jul 1999 20:29:57 GMT Organization: Bailey Network Management Lines: 15 Message-ID: <7nigg5$6k5@web.nmti.com> References: <7lassu$p2q$1@mail.pl.unisys.com> <3794b742@newsread3.dircon.co.uk> NNTP-Posting-Host: wssql01.nmti.com X-Newsreader: trn 4.0-test67 (15 July 1998) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!news-feed.inet.tele.dk!bofh.vszbr.cz!news-proxy.baileynm.com!web.nmti.com!not-for-mail In article <3794b742@newsread3.dircon.co.uk>, Ian Kemmish wrote: >I've dipped into this thread from time to time. No-one seemed to have >mentioned the problem of designing an adder which works with ASCII text. It >seems a comptuer which executed text *directly* would have to be able to cope >with constants before its designers could be allowed to worry about >variables:-) Has someone mentioned the IBM 1620 yet? :-> -- In hoc signo hack, Peter da Silva `-_-' Ar rug tú barróg ar do mhactíre inniu? 'U` << you did technical support for Hell ? Didn't we all, in our youth? >:) >> ###### From: mikekingston@cix.co.uk (Michael J Kingston) Newsgroups: alt.folklore.computers Subject: Re: CPU's directly executing HLL's (was Which programming languages) Date: Mon, 26 Jul 1999 16:31 +0100 (BST) Organization: CIX - Compulink Information eXchange Lines: 16 Message-ID: References: <3797a49a.73682058@news.cadvision.com> Reply-To: mikekingston@cix.co.uk NNTP-Posting-Host: 5300-tele-1-cluster.4.ip-pool.cix.co.uk Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!newsfeed1.uni2.dk!news.algonet.se!algonet!newsfeed.icl.net!ayres.ftech.net!news.ftech.net!peernews.cix.co.uk!news.cix.co.uk!not-for-mail In article <3797a49a.73682058@news.cadvision.com>, Digital.Magic@cadvision.com (John W Hall) wrote: > During my (too short) time at Hursley during my IBM career, I heard > that someone had punched up microcode (there were copper traces on > Mylar sheets, which were stacked and then ferrite cores assembled > through them. The traces went through or past the cores depending on > where holes were punched to cut the traces) that made one of the early > small S/360 do APL as its native language. It was reputedly so blazing > fast that he was instructed to stop and never reveal what he had done. > I mentioned earlier a S360/25 that was microcoded at the Palo Alto Scientific Center for native APL that ran as fast as APL software on the mod 50. Sounds like the same story. Mike Kingston ###### Newsgroups: alt.folklore.computers,comp.arch From: ehrice@his.com (Edward Rice) Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Message-ID: Organization: NDS Date: Wed, 28 Jul 1999 21:49:36 -0400 References: <7lassu$p2q$1@mail.pl.unisys.com> <3794b742@newsread3.dircon.co.uk> <379b99ed.0@news.wizvax.net> NNTP-Posting-Host: pm8-233.his.com Lines: 62 X-Authenticated-User: ehrice Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.rhein-neckar.de!news-kar1.dfn.de!news-han1.dfn.de!news.fh-hannover.de!newsfeed.nacamar.de!nntp.frontiernet.net!nntp.gctr.net!news4.his.com!user In article <379b99ed.0@news.wizvax.net>, multics@wizvax.wizvax.net (Richard Shetron) wrote: > The CISC hardware instruction unit (required on Multics, optional on GCOS) Mandatory on Multics after the 645 wound up; mandatory on GCOS after the 6000-odd (6030, 6050 and 6070 models) were phased out. > descriptors could be any of the follwoing types and conversions would > be done to do the operation specified by the opcode: > > fixed bin (multiple precisions) > float bin (short or long) > float decimal (up to 63 digits) > fixed decimal (not sure of the limit) > ascii text (a number in an ascii text field) > additional types I don't remember Nope -- arithmetic could be performed on the fixed in and float bin you mention above, but that wasn't done with the decimal data unit, it was standard word-oriented register-involving arithmetic instructions. (There were some minor exceptions. As one example, an "AOS" instruction added one to a storage location without the involvement if an explicit register. A small set of semaphore instructions operated without registers as well.) > for add, subtract, multiply, and divide, and descripton could be for > any of the types above so the following statements could be done by one > hardware instruction: > > dcl a fixed bin, b float bin, c char(20); > > a=b+c; > c=a+b; > b=a/c; Not quite. The Extended Instruction Set (EIS) only worked on decimal data and on conversion thereto and therefrom. So if you did what you show just above, many conversions would be needed. However, if the declarations were more like: dcl a fixed dec, b float dec, c packed dec (20); then all would go fine (although not terrifically fast). The data could express... fixed point unsigned fixed point leading sign fixed point trailing sign floating point The manual (AL39, the Multics Processor Manual) explains that the processor handles decimal data as 4-bit bytes internally, truncating 9-bit bytes as they are transferred in and expanding them back to 9-bit bytes as they go back to main memory. In memory as 4-bit, 6-bit or 9-bit strings, no explicit conversion is necessary to perform arithmetic operations on the data, and as you indicate, the byte-sized could be mixed. Arithmetic type could not, though -- it was not possible to add a fixed dec number to a float dec number. ###### From: "Alan T. Bowler" Newsgroups: alt.folklore.computers,comp.arch Subject: Re: CPU's directly executing HLL's (was Re: Which programming languages) Date: Thu, 29 Jul 1999 12:53:35 -0400 Organization: UUNET Canada News Transport Lines: 31 Message-ID: <37A0870F.2CB2E6B0@thinkage.on.ca> References: <7lassu$p2q$1@mail.pl.unisys.com> <3794b742@newsread3.dircon.co.uk> <379b99ed.0@news.wizvax.net> NNTP-Posting-Host: 192.102.11.4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news1.sunrise.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone.bc.net!newsfeed.direct.ca!news.uunet.ca!not-for-mail Edward Rice wrote: > > In article <379b99ed.0@news.wizvax.net>, > multics@wizvax.wizvax.net (Richard Shetron) wrote: > > > The CISC hardware instruction unit (required on Multics, optional on > GCOS) > > Mandatory on Multics after the 645 wound up; mandatory on GCOS after the > 6000-odd (6030, 6050 and 6070 models) were phased out. > The manual (AL39, the Multics Processor Manual) explains that the processor > handles decimal data as 4-bit bytes internally, truncating 9-bit bytes as > they are transferred in and expanding them back to 9-bit bytes as they go > back to main memory. > > In memory as 4-bit, 6-bit or 9-bit strings, no explicit conversion is ^^^^^ > necessary to perform arithmetic operations on the data, and as you > indicate, the byte-sized could be mixed. Arithmetic type could not, though ^^^ > -- it was not possible to add a fixed dec number to a float dec number. ^^^ Close. The EIS instructions will not do arithmetic on 6-bit data. The arithmetic instructions take numeris descriptors and those only use 1 bit to distinguish between 4 and 9 bit data. The non-arithmetic EIS instructions handle 4,6 or 9 bit data. It certainly IS possible to mix fixed and floating decimal operands. You can add a fixed decimal number to a floating decimal number. The C library internal handling of printf does this.