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=1.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1ea19776e3073a96 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: C/C++ programmer giving Ada95 a chance -- writing an emulator. Date: 2000/03/28 Message-ID: #1/1 X-Deja-AN: 603395322 References: <38e148e2.5089627@news.shreve.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 954249641 209.250.225.153 (Tue, 28 Mar 2000 07:20:41 CST) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Tue, 28 Mar 2000 07:20:41 CST Newsgroups: comp.lang.ada Date: 2000-03-28T00:00:00+00:00 List-Id: "jross" wrote in message news:38e148e2.5089627@news.shreve.net... >I was thinking of what kind of application to write to learn Ada and > put it through it paces. Since I have heard that Ada was designed > for system level programming (at the embedded level nonetheless) I > thought what better application to test the language with than an > emulator of an older CPU and its peripherals. I'd like to echo the other comments regarding the difference between learning the Ada language, and learning how to translate between C++ and Ada syntax. For example, most interesting system levels programs require more than a few lines of code. So, one of the first issues to consider is how to partition the system to make it easy to understand, extend, etc. Questions you'd need to ask are: - How do I use packages and types to organize my system? - What information should go in the package specification? The private area of the package spec? The body? Some questions that might be interesting to ask for your specific example, below: - Do I want to use the C++ style names, or something else? - Is a byte the best type for the internal representation of an opcode? More importantly, is it the right representation for users of this functionality? Is it likely to change (affecting all users), and so would another external representation (an enumeration type?) reduce the maintenance impact? - Do I want to be able to change the layout of OpStruct to improve efficiency on certain machines without affecting the users of this functionality? - Do I really want users to declare their own OpStructs, etc.? > My first question is how do you define and write a dispatching > mechanism as you would in C++ using function pointers in a table for > execution speed efficiency, like this: Without thinking excessively hard, and certainly without checking for correctness, I'd probably start with something like: -- file CPU.ads package CPU is -- define registers and much stuff (maybe too much for one package?) type Opcode_Type is ( Jump, Test, Undefined_02, Add ... ); procedure Invoke ( Opcode: in Opcode_Type ); pragma Inline (Invoke); -- might want to declare an Illegal_Opcode exception? private -- declare the internal representation of Opcode_Type here, if needed for Opcode_Type... end CPU; -- file CPU.adb package body CPU is type Operation_Access is access procedure; procedure Undefined_Operation is separate; procedure Jump_Operation is separate; procedure Test_Operation is separate; procedure Add_Operation is separate; -- This may actually be more efficient than your C++ example, since the -- opcode is not explicitly stored... Dispatch_Opcode: constant array (Opcode) of Operation_Access := ( Jump => Jump_Operation'access, Test => Test_Operation'access, Add => Add_Operation'access, ... others => Undefined_Operation'access ); procedure Invoke ( Opcode: in Opcode_Type ) is Dispatch_Opcode(Opcode).all; end Invoke; -- You can also look at moving all the declarations to within Invoke. end CPU; -- definitions of xx_Operation procedure bodies would be -- in separate files. In real life, of course, you might need more than a single value to invoke an instruction. Some architectures have extended opcodes or other modifiers. Therefore, whether the Invoke should be so tightly coupled with Opcode, or whether these should be different packages, is a question to consider.