6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: Dan Lingman on 4 Jun 2006 10:39 "mdj" <mdj.mdj(a)gmail.com> wrote in news:1149428711.900916.89960 @g10g2000cwb.googlegroups.com: > I hope that eventually we'll be dealing with very high abstraction > levels, perhaps languages with its own symbology rather than being > forced into being expressed in roman character sets, etc. There is a > long, long way to go before such ideals are realised though. > Fortunately, some people are beginning to see the light. > > Matt > Pining for APL are we? :-) Dan.
From: Michael J. Mahon on 4 Jun 2006 17:43 Dan Lingman wrote: > "mdj" <mdj.mdj(a)gmail.com> wrote in news:1149428711.900916.89960 > @g10g2000cwb.googlegroups.com: > > >>I hope that eventually we'll be dealing with very high abstraction >>levels, perhaps languages with its own symbology rather than being >>forced into being expressed in roman character sets, etc. There is a >>long, long way to go before such ideals are realised though. >>Fortunately, some people are beginning to see the light. >> >>Matt >> > > > Pining for APL are we? > > :-) Ah--brevity of expression carried to its limit--often described as a "write-only language". ;-) It is interesting to think of APL as a subject for some advanced (dynamic) optimization. It was conceived as a fully interpreted language, encouraging the use of vector and matrix ops that could produce truly huge intermediate data structures, just to eventually boil them down to a scalar. Later implementations introduced optimizations that attempted to create some of the larger data structures "lazily" to save space and time, while leaving the pure algebra of the source APL intact. The "near applicative" nature of APLs semantics was quite well suited to parallel evaluation. I wonder what modern optimization techniques and multiprocessor platforms could do with it today--perhaps with some semantic tweaks to clean things up. Then there's always that amazing keyboard... ;-) -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: mdj on 4 Jun 2006 21:24 Michael J. Mahon wrote: > > Pining for APL are we? > > > > :-) > > Ah--brevity of expression carried to its limit--often described > as a "write-only language". ;-) > > It is interesting to think of APL as a subject for some advanced > (dynamic) optimization. Yes. Many people tend to feel high level languages are inefficient because they're too abstract, but I feel they're inefficient because they're not abstract enough :-) > The "near applicative" nature of APLs semantics was quite well suited > to parallel evaluation. I wonder what modern optimization techniques > and multiprocessor platforms could do with it today--perhaps with some > semantic tweaks to clean things up. I'm very sure we'll end up on a path towards "near applicative" semantics. I imagine libraries of algorithms rather than 'code' and compilers that truly understand computational complexity, plus take full advantage of being able to determine the scope of an object to distill things into extremely efficient machine representations. Couple that with runtime instrumentation during development and test, and some amazing possibilities open up. These days I tend to write things in Ruby, which gives me SmallTalk without SmallTalk, LISP without LISP (Ruby has the 'yield' operator borrowed from CLU), Perl without Perl. It's a great deal of fun to be able to combine full OO, lambda calculus, dynamic rewriting of code, and not have to use something like CLOS. Python has most of the same features, too, but I'm not fond of its syntax so I found myself in the Ruby camp. It's great to be able to use a pure OO scripting language and have the execution speed be very respectable. Matt
From: Paul Schlyter on 5 Jun 2006 11:13 In article <1149383070.763983.291190(a)h76g2000cwa.googlegroups.com>, mdj <mdj.mdj(a)gmail.com> wrote: > Paul Schlyter wrote: > >> I fully agree with that! The API is the specification, not the >> implementation. There might be some parts of the library which >> can be called by outside code but wasn't intended to be called in >> that way - they're not part of the API, even though they're part of >> the library! > > Of course, if you use features of a library that aren't part of it's > documented interface you'll eventually be cursed by almost everybody. > > Hey, we're almost back on topic, considering this was supposed to be > about 'undocumented opcodes' :-) Of course, my feelings on using > undocumented library calls is much the same as my feelings on > undocumented opcodes. They are very similar problems. > > Matt In the Apple II world we had other similar situations: calling Monitor ROM routines at some fixed address. Or calling routines in the Applesoft Basic ROM's. -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/
From: Michael J. Mahon on 5 Jun 2006 15:18
Paul Schlyter wrote: > Some programming languages even had these formatting rules built-in. > In e.g. FORTRAN (up to FORTRAN-77), these rules had to be obeyed: > > Column 1: C or * marked the whole line as a comment > Columns 2-6: Labels went here - 1-5 decimal digits > Column 7: A non-space character here marked this line as a contination line > Columns 8-71: The program statement went here > Columns 72-80: Comment - anything here was ignored by the compiler Actually, it was: Column 1-5: Statement number, or "C" in column 1 for comment lines Column 6: Non-blank marks continuation line (often 1-9 to indicate sequence of the continuations if more than one) Columns 7-72: FORTRAN Statement Columns 73-80: ID/sequence field, ignored by compiler The sequence field was often left blank on manually keypunched cards, but was almost always filled with some combination of a "deck" ID and a sequence number on machine-punched decks, as were "binary" decks. I remember many times using an IBM 82 card sorter to restore order to a deck containing gravity-induced entropy. ;-) There is an interesting historical reason for the FORTRAN compiler to ignore columns 73-80. FORTRAN was first implemented on the IBM 704 computer, and that machine and its successors, the 709, 7090, 7040, and 7094, all used a binary card console card reader that read in "row binary". Since these machines had 36-bit words, the standard binary card format was 12 pairs of 36-bit words, read from successive rows of the card, and therefore covering only the first 72 columns. As a result, the computer could not read columns 73-80 from the console card reader, and those columns were already conventionally used for deck sequence numbers. FORTRAN merely continued that convention. And, of course, what the computer could not read, the compiler must ignore. ;-) For example, see: www.atkielski.com/PDF/data/fortran.pdf -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused." |