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: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: Scott Johnson Subject: Re: Ada vs C++ vs Java Date: 1999/01/27 Message-ID: <36AFF210.27EA@nospam.aracnet.com>#1/1 X-Deja-AN: 437816636 Content-Transfer-Encoding: 7bit References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> <77pnqc$cgi$1@newnews.global.net.uk> <8p64spq5lo5.fsf@Eng.Sun.COM> <782r25$k18$1@nnrp1.dejanews.com> <36AEDCEE.23964EF7@enea.se> Content-Type: text/plain; charset=us-ascii Organization: National Association for the Advancement of Computer Geeks Mime-Version: 1.0 Reply-To: sj_nospam@nospam.aracnet.com Newsgroups: comp.lang.ada,comp.vxworks,comp.realtime Date: 1999-01-27T00:00:00+00:00 List-Id: Ola Liljedahl wrote: > > robert_dewar@my-dejanews.com wrote: > > > > > > Assembly language is simpler than any high-order > > > language, but it's lots more work to code in assembly. > > > > Now let me guess. The last time you looked at machine > > language was in the 80's, right? Yes, in those days, the > > semantics of machine language was pretty simple. > > > > I am afraid that things have changed. At this stage the > > full execution semantics of a modern chip with extensive > ^^^^^^^^^ > > instruction-level parallelism is remarkably complex along > > ALL the dimensions I mention above. A chip like the Pentium > > II, if you include efficiency issues, which are indeed not > > fully documented publicly, let alone formally specified, > > you have something far MORE complicated than any of the > > languages we are talking about here. > > Wrong. The semantics of the assembly level instructions is > for all CPU architectures I know of (68K, SPARC, PowerPC) > extremely simple. The semantics is that of a sequential > execution of instructions where each instruction complete > before the next is executed. That a particual implementation > is actually pre-fetching instructions, using branch prediction, > out of order issue and completion etc etc etc does NOT affect > the semantics. All these implementation details ONLY affect > the performance of the implementation, not the semantics. Not always true. For acessing RAM, which does not suffer from out-of-order or speculative accesses, the above is true. However, writers of device drivers for RISC machines had BETTER know what they are doing--a speculative fetch that is harmless when done to RAM may crash the system (or do something else nasty) when done to a register. Fortunately, the processors have instructions to enforce in-order execution, and ways (usually via the MMU) to mark regions of memory as guarded (to disable speculative access). Anybody who write a device driver for the PowerPC, though, and who intends to have the MMU enabled, had best make LIBERAL use of the EIEIO instruction. (That mnemonic is proof that SOMEONE at IBM has a sense of humor...) Need I mention architectures with branch delay slots and other "let the compiler figure it out" violations of the sequential execution model??? Scott