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: f849b,869d7890f1bd9878 X-Google-Attributes: gidf849b,public X-Google-Thread: 103376,869d7890f1bd9878 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-18 08:27:53 PST Message-ID: <3E525D7D.BA64EE12@acm.org> Date: Tue, 18 Feb 2003 09:21:18 -0700 From: Thad Smith Organization: T3 Systems X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.arch.embedded Subject: Re: Type-safe low-level programming? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 206.124.6.194 X-Trace: omega.dimensional.com 1045585655 206.124.6.194 (18 Feb 2003 09:27:35 -0700) Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!mtvwca1-snh1.ops.genuity.net!paloalto-snf1.gtei.net!news.gtei.net!dimensional.com!pulsar.dimensional.com!omega.dimensional.com!not-for-mail Xref: archiver1.google.com comp.lang.ada:34199 comp.arch.embedded:59735 Date: 2003-02-18T09:21:18-07:00 List-Id: Hans-Bernhard Broeker wrote: > > In comp.arch.embedded Bernd Trog wrote: > > > Now I wonder, if its possible to make 'Set_Bit' type-safe *without* > > increasing the program memory size for every new register? > > The only way I see is to drop the idea of passing the register and the > bit number inside that register as independent parameters --- they > aren't independent, and pretending they are is what causes your grief. > The need to introduce a comment to explain what Bit_A1 is supposed to > mean should have given you the hint. > > What you need would be more like > > type Bit_Number is range 0 .. 8*16#ff#); > > Register_A : constant Address_Type := 1; > > Bit_A1 : constant Bit_Number := Register_A*8 + 4; > Bit_A2 : constant Bit_Number := Register_A*8 + 1; Good point. A note to fellow comp.arch.embedded readers: this also works as well in other languages. I have used a similar scheme in C and assembly, bundling the port address and bit number and number of bits and bit polarity into a single macro definition. A single macro invocation, such as SetOutput (RF_ATTENUATOR, 1); can be used to set the correct bit in the correct port. An I/O definition header file defines all I/O signals in terms of the application, not port/bit names. Changing the port assignment or inverting the sense of an I/O signal is done in the definition file. The code generated is close to optimal, since the compiler is working on constant definitions, which it can optimize well and no function calls are required. The biggest downside is that the macro definitions (in C) look like a bowl of Chinese Alphabet soup to handle all the details. Thad