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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78b2880bc7e78e39 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-14 13:58:08 PST Path: supernews.google.com!sn-xit-03!supernews.com!cyclone-sf.pbi.net!151.164.30.35!cyclone.swbell.net!bos-service1.ext.raytheon.com!cambridge1-snf1.gtei.net!news.gtei.net!inmet!not-for-mail From: Tucker Taft Newsgroups: comp.lang.ada Subject: Re: RISC Date: Wed, 14 Mar 2001 16:57:59 -0500 Organization: AverStar (formerly Intermetrics) Burlington, MA USA Message-ID: <3AAFE967.44BAEDAD@averstar.com> References: NNTP-Posting-Host: nebula.burl.averstar.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: inmet2.burl.averstar.com 984607080 19513 141.199.8.77 (14 Mar 2001 21:58:00 GMT) X-Complaints-To: usenet@inmet2.burl.averstar.com NNTP-Posting-Date: 14 Mar 2001 21:58:00 GMT X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:5739 Date: 2001-03-14T21:58:00+00:00 List-Id: "chris.danx" wrote: > > Hi, > I'm simulating a RISC machine in Ada. Eventually the instructions will > be mapped to native architecture (x86, m68xxx, SPARC, etc), but for now i > want to simulate a machine, to limit the possibility of doing something > nasty to anyone's machine. > > I've decided to provide byte, word and long word modes for most > instructions. The problem comes when clearing or setting byte or word > portions of a register (the machine is loosely based on M68000). The > register is long word (32bit) and i want to set the lower 16bits or 8bits. > I've managed to get this to work, problem is it's not very efficient. > > The register is of type 'mod', so i divided by 2**8 or 2**16 then multiplied > by it. I know multiplication and division are costly and really i'm looking > for something more efficient. If this were Pascal i'd use 'shift > left/right' which is quite fast. What should i do to speed it up? Does Ada > have a shift L/R operation? Is there another way to do it? There are a few: 1) Declare a record type (or types) and use a record rep clause (or clauses) to define the fields you are interested in. 2) Use Interfaces.Unsigned_* and use the shifting operations there 3) Use a packed bit array and use slicing (efficiency will probably vary significantly from compiler to compiler on this one) 4) Use a modular type and use "and" with 255 or 65535 to extract the low-order 8/16 bits. > > I have another problem with memory. I thought about allocating one big > block of memory (as an array) and accessing it by index. The problem? I do > plan to dynamically allocate the memory, but i'll still be limited by the > amount of memory allocable in a single array. I've thought of a few ways of > doing this but can't seem to avoid problems! Anyone know of a solution? I > don't like using C, but i 'd run in to a similar problem binding with C > anyway. One good way to deal with large address spaces is to break the address up into a page index and an offset within page, or even a segment/page/offset. E.g., the segment is the high 12 bits, the page index is the next 8 bits, and the offset within page is the low-order 12 bits. You then have a top-level segment table with 4096 segments, each of which is either null, if nothing has ever been written into that segment, or a pointer to a 256-entry page table. Each entry in the page table is similarly either null, or a pointer to a 4096-byte page, depending on whether anything has ever been written to that page. When reading memory, if the corresponding segment or page entry is null, just return a 0. When writing memory, if the corresponding segment or page entry is null, and the value being written is other than 0, allocate the page, and page table if necessary, and update the segment/page entries to point to these new memory chunks, and then update the appropriate byte(s) in the page. This is essentially one kind of "sparse" array. It also happens to correspond to a way that virtual memory is implemented by a typical MMU. > Thanks, > Chris Campbell > > p.s. This isn't a homework assignment!!! -- -Tucker Taft stt@avercom.net http://www.averstar.com/~stt/ Chief Technology Officer, AverCom Corporation (A Titan Company) Burlington, MA USA (AverCom was formerly the Commercial Division of AverStar: http://www.averstar.com/services/ebusiness_applications.html)