From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ef33c33c4f98bde1 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Compiler for Z80/6510 Date: 1999/12/02 Message-ID: <1999Dec2.080628.1@eisner>#1/1 X-Deja-AN: 555772158 References: <3845D4B4.98354460@mitre.org> X-Trace: news.decus.org 944139992 8658 KILGALLEN [216.44.122.34] Organization: LJK Software Reply-To: Kilgallen@eisner.decus.org.nospam Newsgroups: comp.lang.ada Date: 1999-12-02T00:00:00+00:00 List-Id: In article <3845D4B4.98354460@mitre.org>, "Robert I. Eachus" writes: > Now this is a pretty special case, but in general modern processors > have hundreds of special purpose operations which are not available from > the assembler. This is because the Assembler limits itself to the set > of instructions specified for all the implementations of the > architecture. For example, on Sun SPARCs, at first it was the case that > you could use (integer) multiply and divide operations which weren't > available in compiler generated code, but could be generated by the > assembler. Then it was possible to provide (in Ada terms) code inserts > that generated these instructions. Then the compilers started > generating them. Next the OS provided routines which trapped the > instructions if not provided by the particular chip you were running on, > etc. But about when the version 8 SPARC reference came out, things > proceded in exactly the reverse order with some of the new instructions: > the assembler was the last to support them. (I could go into details, > but there were serious timing issues for these instructions, and it ws > thought that they would only be used in compiler run-times for special > purposes.) So for a while, I had some Ada code for the SPARC that ran > faster than the tightest assembler I could write. > > Currently we are in this regime again. The Intel Pentium II & III > and the Athelon processor have different graphics support enhancements. > We could argue which is better, but using special libraries and > run-times, in some cases special to both the chip AND the graphics card, > you can generate code which is significantly faster than any Pentium > assembly code. Let me give a counter-example. Macro-64 on Alpha VMS certainly does not contain anything specific to versions of the architecture not yet designed :-), but it does allow you to specify your own instruction definitions, so any possible bit combination for an instruction is attainable. Larry Kilgallen