* Bit manipulation @ 2000-11-07 0:00 Sandro Binetti 2000-11-07 0:00 ` gdemont ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Sandro Binetti @ 2000-11-07 0:00 UTC (permalink / raw) Hi, is there anyone who can help me with bit manipulation on objects like integers or character? Which way may I shift bits, or maskerade them? -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-07 0:00 Bit manipulation Sandro Binetti @ 2000-11-07 0:00 ` gdemont 2000-11-08 7:22 ` Sandro Binetti 2000-11-07 0:00 ` Larry Kilgallen 2000-11-10 7:24 ` Thank you all for your contribution ! Sandro Binetti 2 siblings, 1 reply; 71+ messages in thread From: gdemont @ 2000-11-07 0:00 UTC (permalink / raw) > is there anyone who can help me with bit manipulation on objects like > integers or character? > > Which way may I shift bits, or maskerade them? Look for modular types (e.g. type byte is mod 2**8 and the types in Interfaces package (unsigned_8 etc.)). With them you can "and", "or", "not", "xor" and shift. Look at... http://www.adapower.com/rm95/index.html HTH _____________________________________________ Gautier -- http://members.nbci.com/gdemont/ Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-07 0:00 ` gdemont @ 2000-11-08 7:22 ` Sandro Binetti 0 siblings, 0 replies; 71+ messages in thread From: Sandro Binetti @ 2000-11-08 7:22 UTC (permalink / raw) In article <8u9gl2$qbk$1@nnrp1.deja.com>, gdemont@my-deja.com wrote: > Look at... http://www.adapower.com/rm95/index.html OK! Added to my bookmarks! Thanks a lot. -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-07 0:00 Bit manipulation Sandro Binetti 2000-11-07 0:00 ` gdemont @ 2000-11-07 0:00 ` Larry Kilgallen 2000-11-07 0:00 ` John English ` (2 more replies) 2000-11-10 7:24 ` Thank you all for your contribution ! Sandro Binetti 2 siblings, 3 replies; 71+ messages in thread From: Larry Kilgallen @ 2000-11-07 0:00 UTC (permalink / raw) In article <8u8v6n$b7o$1@nnrp1.deja.com>, Sandro Binetti <sandrobinetti@my-deja.com> writes: > Hi, > is there anyone who can help me with bit manipulation on objects like > integers or character? > > Which way may I shift bits, or maskerade them? Quite often when someone wants to do something like that, they had formerly programmed in some other language whose ability to define data types is not so robust as Ada. Except for the particular situation of changing case of an ASCII Roman letter (for which Ada95 has built-in capabilities), flipping a bit in a character is totally meaningless. If you really meant to blip a bit in a data cell that happens to be 8 bits wide, then please study record and array declarations in an introductory Ada text. If you have to match some external standard, such as hardware or a program written in another language, look at the part about representation clauses. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-07 0:00 ` Larry Kilgallen @ 2000-11-07 0:00 ` John English 2000-11-08 0:00 ` gdemont 2000-11-08 7:18 ` Sandro Binetti 2 siblings, 0 replies; 71+ messages in thread From: John English @ 2000-11-07 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > Except for the particular situation of changing case of an ASCII > Roman letter (for which Ada95 has built-in capabilities), flipping > a bit in a character is totally meaningless. Not so -- consider simple encryption techniques involving xoring character codes. I'm sure there must be other useful examples. ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-07 0:00 ` Larry Kilgallen 2000-11-07 0:00 ` John English @ 2000-11-08 0:00 ` gdemont 2000-11-08 0:00 ` Robert Dewar 2000-11-08 7:18 ` Sandro Binetti 2 siblings, 1 reply; 71+ messages in thread From: gdemont @ 2000-11-08 0:00 UTC (permalink / raw) Larry: > Quite often when someone wants to do something like that, they had > formerly programmed in some other language whose ability to define > data types is not so robust as Ada. May I remark that the main question is not: "I'm stupid and hopeless since I didn't discover until now the benefits of this absolutely superior language called Ada, but I still want to do these ugly manipulations I'm accustomed to, so how do I do them ?". But: "Which way may I shift bits, or maskerade them?" And your hint about using records, arrays and representation clauses is completely overkill just for blipping bits! Please give constructive answers! ______________________________________________________ Gautier -- http://members.nbci.com/gdemont/gsoft.htm Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` gdemont @ 2000-11-08 0:00 ` Robert Dewar 2000-11-08 0:00 ` Sandro Binetti ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Robert Dewar @ 2000-11-08 0:00 UTC (permalink / raw) In article <8ub6kt$6nd$1@nnrp1.deja.com>, gdemont@my-deja.com wrote: > But: > "Which way may I shift bits, or mask them?" > > And your hint about using records, arrays and representation > clauses is completely overkill just for blipping bits! Please > give constructive answers! Nope! When someone asks how can I do "xxx" and xxx is a low level implementation technique, it is always appropriate to enquire as to what the problem is. A C programmer is used to shifting and masking as a solution for all sorts of problems. Now there are cases where such a solution is appropriate in Ada, which is why the capability was added in Ada 95, but compared to C, they are few and far between. Clearly the underlying question is "how do I do shifts and masks to achieve xxx", and to accurately answer this question we need to ask what xxx is. Quite likely the answer will be "don't use shifts and masks to achieve xxx if you are writing Ada, instead use yyy". Of course we could give a simple answer involving the obvious solution of converting Character'Pos values to a modular type and then doing shifts and masks in the normal manner, but that would be a disservice. I see a *lot* of code that is clearly written by C programmers and greatly overuses low level bit twiddling techniques that are appropriate to C but not to Ada. If someone simply wants to get a job done in the dirtiest possible fashion, and wants someone else to do the work, CLA is not the place to expect free help :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Robert Dewar @ 2000-11-08 0:00 ` Sandro Binetti 2000-11-08 0:00 ` Nicolas Brunot ` (4 more replies) 2000-11-08 0:00 ` gdemont 2000-11-11 0:00 ` Redryder 2 siblings, 5 replies; 71+ messages in thread From: Sandro Binetti @ 2000-11-08 0:00 UTC (permalink / raw) In article <8ubeq8$cgm$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > Nope! When someone asks how can I do "xxx" and xxx is a low > level implementation technique, it is always appropriate to > enquire as to what the problem is. > > A C programmer is used to shifting and masking as a solution > for all sorts of problems. Now there are cases where such > a solution is appropriate in Ada, which is why the capability > was added in Ada 95, but compared to C, they are few and > far between. I'm an ADA programmer since 1989; I've written millions of lines of ADA code, developped systems that, fortunately, runs without "unhandled exceptions". I say SYSTEMS, not little PROGRAMS, with lines and lines of generic instantiation, exception handlers, tasks that wait each other in respect of strict time constraints, and so on. But the real fact is not this. My ADA code has, always, a little (very little) part made of "pragma INTERFACES" to C language, in order to manage certain Unix or Linux kernel capabilities (curses, for example). So, once again, the question is the following: IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS, WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL- TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL MANIPULATION IN C LANGUAGE? If you can give me a simple answer... -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Sandro Binetti @ 2000-11-08 0:00 ` Nicolas Brunot 2000-11-08 0:00 ` gdemont ` (3 subsequent siblings) 4 siblings, 0 replies; 71+ messages in thread From: Nicolas Brunot @ 2000-11-08 0:00 UTC (permalink / raw) That's quite interested to read, and illustrate the 'Ada student homework' thread. If this kind of post were more often read, perhaps Ada would be more likely to be used by software companies, and less ruled by unrealistic scholar fanatics ... Sandro Binetti a �crit : > In article <8ubeq8$cgm$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> wrote: > > > Nope! When someone asks how can I do "xxx" and xxx is a low > > level implementation technique, it is always appropriate to > > enquire as to what the problem is. > > > > A C programmer is used to shifting and masking as a solution > > for all sorts of problems. Now there are cases where such > > a solution is appropriate in Ada, which is why the capability > > was added in Ada 95, but compared to C, they are few and > > far between. > > I'm an ADA programmer since 1989; I've written millions of lines of ADA > code, developped systems that, fortunately, runs without "unhandled > exceptions". I say SYSTEMS, not little PROGRAMS, with lines and lines > of generic instantiation, exception handlers, tasks that wait each > other in respect of strict time constraints, and so on. > > But the real fact is not this. > > My ADA code has, always, a little (very little) part made of "pragma > INTERFACES" to C language, in order to manage certain Unix or Linux > kernel capabilities (curses, for example). > > So, once again, the question is the following: > > IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS, > WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL- > TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL > MANIPULATION IN C LANGUAGE? > > If you can give me a simple answer... > -- > Ciao, Sandro > > Sent via Deja.com http://www.deja.com/ > Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Sandro Binetti 2000-11-08 0:00 ` Nicolas Brunot @ 2000-11-08 0:00 ` gdemont 2000-11-09 4:00 ` Ken Garlington 2000-11-08 0:00 ` Dale Stanbrough ` (2 subsequent siblings) 4 siblings, 1 reply; 71+ messages in thread From: gdemont @ 2000-11-08 0:00 UTC (permalink / raw) > If you can give me a simple answer... Ada95: you can do everything in Ada (of course, it can be useful to re-use parts already programmed in C or Fortran) Ada83: for certain things like bit manipulations, you have to use compiler-dependent libraries or interface with bits of code in C. HTH ______________________________________________________ Gautier -- http://members.nbci.com/gdemont/gsoft.htm PS: so, if your instructor... bla bla.. you should... bla bla bla... the true Ada programmers do... bla bla... your homework assignment... bla bla... never do that... bla bla bla bla... find a good book and read it... bla bla... PPS: just kidding - from a pure user. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` gdemont @ 2000-11-09 4:00 ` Ken Garlington 2000-11-09 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 71+ messages in thread From: Ken Garlington @ 2000-11-09 4:00 UTC (permalink / raw) : Ada83: for certain things like bit manipulations, you have to : use compiler-dependent libraries or interface with bits : of code in C. I've done huge numbers of bit manipulations in Ada83 without doing either of these options. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 4:00 ` Ken Garlington @ 2000-11-09 0:00 ` Larry Kilgallen 2000-11-09 0:00 ` Ken Garlington 0 siblings, 1 reply; 71+ messages in thread From: Larry Kilgallen @ 2000-11-09 0:00 UTC (permalink / raw) In article <yjpO5.8905$pq3.719737@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> writes: > : Ada83: for certain things like bit manipulations, you have to > : use compiler-dependent libraries or interface with bits > : of code in C. > > I've done huge numbers of bit manipulations in Ada83 without doing either of > these options. Perhaps what you have written would not be portable to another compiler. Perhaps that is immaterial in your problem domain. It is in one of mine. But now I have an additional problem domain where portability becomes more important, so I am happy the effort went into Ada95. Larry Kilgallen Ada83 programmer ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 0:00 ` Larry Kilgallen @ 2000-11-09 0:00 ` Ken Garlington 0 siblings, 0 replies; 71+ messages in thread From: Ken Garlington @ 2000-11-09 0:00 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message news:4bHjnjxVodhb@eisner.decus.org... : In article <yjpO5.8905$pq3.719737@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> writes: : > : Ada83: for certain things like bit manipulations, you have to : > : use compiler-dependent libraries or interface with bits : > : of code in C. : > : > I've done huge numbers of bit manipulations in Ada83 without doing either of : > these options. : : Perhaps what you have written would not be portable to another compiler. : Perhaps that is immaterial in your problem domain. It is in one of mine. So far, it's survived five compilers (TeleSoft, Tartan, Alsys, Green Hills, Texas Instruments) and four processors (1750, 80x86, PowerPC, C67) with little or no modifications required - see, for example: http://www.lmaeronautics.com/news/press/jsf/jsfpr000531.html See also the C_Coder_Test procedure I posted elsewhere in this thread, which does (unncessary) bit masking, etc. It should work on just about any compiler (Ada83 or Ada95), as far as I know. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Sandro Binetti 2000-11-08 0:00 ` Nicolas Brunot 2000-11-08 0:00 ` gdemont @ 2000-11-08 0:00 ` Dale Stanbrough 2000-11-09 0:00 ` Sandro Binetti 2000-11-09 3:59 ` Ken Garlington 2000-11-09 4:52 ` Robert Dewar 4 siblings, 1 reply; 71+ messages in thread From: Dale Stanbrough @ 2000-11-08 0:00 UTC (permalink / raw) Sandro Binetti wrote: > My ADA code has, always, a little (very little) part made of "pragma > INTERFACES" to C language, in order to manage certain Unix or Linux > kernel capabilities (curses, for example). > > So, once again, the question is the following: > > IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS, > WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL- > TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL > MANIPULATION IN C LANGUAGE? You use one argument ("i have to use Unix or Linux kernel capabilties") to bring us to a second argument ("i have to do low level manipulation in C"). The answer to the first argument is that you use C to call Unix routines because either the ABI is a C like one e.g. execv does not have to be written in C, but the calling notations use the C language to describe it. Most of the time it is also written in C, but this may not always be the case. (is the entire POSIX compatability library for VMS written in C?). the routine you are calling is in C. You call the routines because they are there, and it's cheaper than rewriting them. Nothing wrong with that. The second argument, that you -have- to use low level manipulation in C, is not supported by any examples. I'm struggling to think up an example for which this is the case. Could you provide an example? Dale ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Dale Stanbrough @ 2000-11-09 0:00 ` Sandro Binetti 2000-11-09 0:00 ` Ken Garlington ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Sandro Binetti @ 2000-11-09 0:00 UTC (permalink / raw) In article <dale-E44FBB.07363509112000@news-server>, Dale Stanbrough <dale@cs.rmit.edu.au> wrote: > > The answer to the first argument is that you use C to call Unix routines > because either [ ... snip ...] OK! You're quite right! This first case is meaningless. > > The second argument, that you -have- to use low level manipulation > in C, is not supported by any examples. There are, IMHO, two different languages: 1) the language used by hardware engineers 2) the (O.O.) programming languages used by the software developpers that should use the hardware devices sub 1) The language sub 1) is, quite often, bit-manipulation oriented (mask the 4 MSB to obtain XXX, shift twice leftmost in the register YYY to set the device status in ZZZ mode, and so on ...) The language sub 2), say ADA, has to make an abstraction of these hardware specifications, or, simply, use them? Is it correct, in a teamwork made of a lot of engineers and programmers that exchange documentation each other, arbitrarily "upset" a bit- oriented specification, given as a starting point for a subsequent software developement, in order to "match" ADA high-level point of view? Of course, a correctly analized problem has to be faced in a "high- level" way, this is the case of certain kind of systems developped inside the O.O. paradigm constraints. But, how to face a low-level explained problem? Using a low-level language? -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 0:00 ` Sandro Binetti @ 2000-11-09 0:00 ` Ken Garlington 2000-11-09 0:00 ` gdemont 2000-11-10 0:00 ` Scott Ingram 2 siblings, 0 replies; 71+ messages in thread From: Ken Garlington @ 2000-11-09 0:00 UTC (permalink / raw) "Sandro Binetti" <sandrobinetti@my-deja.com> wrote in message news:8udr5g$d6t$1@nnrp1.deja.com... : In article <dale-E44FBB.07363509112000@news-server>, : Dale Stanbrough <dale@cs.rmit.edu.au> wrote: : > : > The answer to the first argument is that you use C to call Unix : routines : > because either : : [ ... snip ...] : : OK! You're quite right! This first case is meaningless. : : > : > The second argument, that you -have- to use low level manipulation : > in C, is not supported by any examples. : : There are, IMHO, two different languages: : 1) the language used by hardware engineers : 2) the (O.O.) programming languages used by the software developpers : that should use the hardware devices sub 1) : : The language sub 1) is, quite often, bit-manipulation oriented (mask : the 4 MSB to obtain XXX, shift twice leftmost in the register YYY to : set the device status in ZZZ mode, and so on ...) Hardware engineers often speak this way -- if their experience is limited to C and assembly, where those are the only features open to them. On the other hand, it's not hard to teach them to actually say what they want (in turn, "XXX is defined as the Y low-order bits," "set register YYY to four times it's current value to active ZZZ mode," and so on ...) : The language sub 2), say ADA, has to make an abstraction of these : hardware specifications, or, simply, use them? Hopefully, it both uses _and_ abstracts them, particularly if they are likely to change. : Is it correct, in a teamwork made of a lot of engineers and programmers : that exchange documentation each other, arbitrarily "upset" a bit- : oriented specification, given as a starting point for a subsequent : software developement, in order to "match" ADA high-level point of view? Not where I work! You confuse the concept of a bit-oriented specification (e.g., "Bits 7-9 of Register FOO are used to set the error code") with the operations needed to manipulate FOO. In Ada, I simply describe FOO with a record representation specification, usually pulled almost verbatim from the hardware specification. Then, I let the compiler worry about the operations needed to manipulate it for a given target architecture (and, yes, we have cases where the target changes, but the hardware interface doesn't). Perhaps a specific example would help. I searched the Internet for a "status register layout" and found the following: http://www.devresource.hp.com/devresource/Docs/Refs/IA64ISA/fp_program3.html #79426 (You may need to unwrap the URL if it is split across multiple lines). Here's an Ada package that (semi-)describes this status register: package Floating_Point_Status_Register is -- I'm too lazy to look up the bit-ordering, so I'll just assume... type Trap_Options_Type is ( Inexact_Disabled, Underflow_Disabled, Overflow_Disabled, Zero_Divide_Disabled, Denormal_Unnormal_Operand_Disabled, Invalid_Operation_Disabled ); type Traps_Type is array (Trap_Options_Type) of Boolean; pragma Pack (Traps_Type); -- I'm going to ignore the actual layout of status fields -- in the interest of time... type Status_Field_Type is range 0 .. 16#1FFF#; for Status_Field_Type'Size use 13; type Reserved_Field_Type is range 0 .. 8#77#; for Reserved_Field_Type'Size use 6; type Object_Type is record Reserved : Reserved_Field_Type; Alternate_Status_3 : Status_Field_Type; Alternate_Status_2 : Status_Field_Type; Alternate_Status_1 : Status_Field_Type; Main_Status : Status_Field_Type; Traps : Traps_Type; end record; for Object_Type use record Reserved at 0 range 0 .. 5; Alternate_Status_3 at 0 range 6 .. 18; Alternate_Status_2 at 0 range 19 .. 31; Alternate_Status_1 at 0 range 32 .. 44; Main_Status at 0 range 45 .. 57; Traps at 0 range 58 .. 63; end record; for Object_Type'Size use 64; function Object return Object_Type; procedure Set (Object : in Object_Type); end Floating_Point_Status_Register; Now, let's say I want to test the Traps field to see if Underflow is disabled and Overflow isn't. The average programmer attempting to write C in Ada83 might decide to do the following: with Floating_Point_Status_Register; procedure C_Coder_Test is package FPSR renames Floating_Point_Status_Register; use FPSR.; Under_Over_Mask : constant FPSR.Traps_Type := (false, true, true, false, false, false); Under_Over_Test : constant FPSR.Traps_Type := (false, true, false, false, false, false); Register : FPSR.Object_Type; begin Register := FPSR.Object; if (Register.Traps and Under_Over_Mask) = Under_Over_Test then null; -- whatever end if; end; On the other hand, the average Ada83 programmer might write: with Floating_Point_Status_Register; procedure Test is package FPSR renames Floating_Point_Status_Register; use FPSR; Register : constant FPSR.Object_Type := FPSR.Object; begin if Register.Traps(Underflow_Disabled) and not Register.Traps(Overflow_Disabled) then null; -- whatever end if; end; It is left as an exercise which solution is "better" in a software engineering sense. :) : Of course, a correctly analized problem has to be faced in a "high- : level" way, this is the case of certain kind of systems developped : inside the O.O. paradigm constraints. But, how to face a low-level : explained problem? Using a low-level language? Nope, use the high-level features of a language expressly designed to support bit-oriented hardware protocols. There are certainly cases where explicit bit-level operations (and, or, xor...) are useful, such as the encryption example previously cited, and in fact Ada83 implements them directly for arrays of Boolean. You can also convert most other types in Ada83 to Boolean arrays, although you do have to be careful to minimize portability effects. Ada95 provides additional capabilities with modular types, as previously mentioned. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 0:00 ` Sandro Binetti 2000-11-09 0:00 ` Ken Garlington @ 2000-11-09 0:00 ` gdemont 2000-11-10 0:00 ` Scott Ingram 2 siblings, 0 replies; 71+ messages in thread From: gdemont @ 2000-11-09 0:00 UTC (permalink / raw) Sandro Binetti: > There are, IMHO, two different languages: > 1) the language used by hardware engineers > 2) the (O.O.) programming languages used by the software developpers > that should use the hardware devices sub 1) > The language sub 1) is, quite often, bit-manipulation oriented (mask > the 4 MSB to obtain XXX, shift twice leftmost in the register YYY to > set the device status in ZZZ mode, and so on ...) > > The language sub 2), say ADA, has to make an abstraction of these > hardware specifications, or, simply, use them? The 1)-2) hiatus is very classic because older languages did fit only for a part of computing (C for bits, Fortran for maths, Pascal for abstraction). The good news is that Ada covers 1) as well as 2). In addition, IHMO Ada95 offers more powerful (read: precise) tools for 1) than C, e.g. . > Is it correct, in a teamwork made of a lot of engineers and programmers > that exchange documentation each other, arbitrarily "upset" a bit- > oriented specification, given as a starting point for a subsequent > software developement, in order to "match" ADA high-level point of > view? Ideally the "low-level" engineers write their hardware/IO packages in Ada, the "high-level" ones write their maths, OO etc. in other packages also in Ada. Finally a "gnatmake the_big_project" to build the whole. In a funny domain you can see in my 3D sources (URL below - and sorry for the auto-advertisement...) an example of project where Ada covers all levels: (1) reprogramming keyboard interrupt, timer interrupt, drawing pixels for textured objects with heavy use of bit masking and shifting, (2) rendering, rotations, projections, management of "universes" and even (3) organizing interactive scenes (at this stage the Ada source ressembles to a script) and manipulating 3D models directly stored in large Ada constant arrays (instead of loading a VRML). The modularity of Ada allows to combine all levels quite easily. ____________________________________________________ Gautier -- http://members.nbci.com/gdemont/e3d.htm Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 0:00 ` Sandro Binetti 2000-11-09 0:00 ` Ken Garlington 2000-11-09 0:00 ` gdemont @ 2000-11-10 0:00 ` Scott Ingram 2 siblings, 0 replies; 71+ messages in thread From: Scott Ingram @ 2000-11-10 0:00 UTC (permalink / raw) Sandro Binetti wrote: > > There are, IMHO, two different languages: > 1) the language used by hardware engineers > 2) the (O.O.) programming languages used by the software developpers > that should use the hardware devices sub 1) > > -- > Ciao, Sandro In our group, we use VHDL and schematic capture tools that readily provide an abstract model. In our case, we actually have to break down our models to bits so that the software guys can understand the interface because they are using C. Go figure. -- Scott Ingram Vice-Chair, Baltimore SIGAda Sonar Processing and Analysis Laboratory Johns Hopkins University Applied Physics Laboratory ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Sandro Binetti ` (2 preceding siblings ...) 2000-11-08 0:00 ` Dale Stanbrough @ 2000-11-09 3:59 ` Ken Garlington 2000-11-09 4:52 ` Robert Dewar 4 siblings, 0 replies; 71+ messages in thread From: Ken Garlington @ 2000-11-09 3:59 UTC (permalink / raw) "Sandro Binetti" <sandrobinetti@my-deja.com> wrote in message news:8ubld2$hdd$1@nnrp1.deja.com... : So, once again, the question is the following: : : IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS, : WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL- : TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL : MANIPULATION IN C LANGUAGE? I give up - why do you? Ken Garlington (who has developed and fielded Ada code for complex uncommercial devices, e.g. MIL-STD-1553B aerospace bus, since 1984 without once using low level manipulation in C language) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Sandro Binetti ` (3 preceding siblings ...) 2000-11-09 3:59 ` Ken Garlington @ 2000-11-09 4:52 ` Robert Dewar 4 siblings, 0 replies; 71+ messages in thread From: Robert Dewar @ 2000-11-09 4:52 UTC (permalink / raw) In article <8ubld2$hdd$1@nnrp1.deja.com>, Sandro Binetti <sandrobinetti@my-deja.com> wrote: > IF I HAVE TO MANAGE A COMPLEX UNCOMMERCIAL DEVICE, SAY A SATELLITE BUS, > WHY DO I HAVE TO WRITE ALL THE CODE USING ADA (IMPOSED FOR THESE REAL- > TIME ORIENTED APPLICATIONS) AND, AT A CERTAIN MOMENT, USE LOW LEVEL > MANIPULATION IN C LANGUAGE? A simple answer is that you don't! There is almost no legitimate reason for going to C if you are using Ada 95. As many people have told you in this thread, modular types give you all the capabilities you have in C for low level bit twiddling. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Robert Dewar 2000-11-08 0:00 ` Sandro Binetti @ 2000-11-08 0:00 ` gdemont 2000-11-08 0:00 ` Larry Kilgallen 2000-11-09 4:47 ` Robert Dewar 2000-11-11 0:00 ` Redryder 2 siblings, 2 replies; 71+ messages in thread From: gdemont @ 2000-11-08 0:00 UTC (permalink / raw) > Of course we could give a simple answer involving the > obvious solution of converting Character'Pos values to > a modular type and then doing shifts and masks in the > normal manner, but that would be a disservice. > > I see a *lot* of code that is clearly written by C programmers > and greatly overuses low level bit twiddling techniques that > are appropriate to C but not to Ada. > > If someone simply wants to get a job done in the dirtiest > possible fashion, and wants someone else to do the work, > CLA is not the place to expect free help :-) I'm not sure that Mr Binetti intends to do dirty things. After all, the conversions like Character'Pos <-> modular or signed <-> modular precisely draw the attention about when you enter the realm of bit twiddling on a certain number of bits, and when some bit and bit length have a special meaning. They are verbose enough to be re-found after a while, and to discourage using them when a "* (2**7)" or a "mod 32" suffices. The dirty thing would be e.g. to allow bit twiddling on a signed integer, and this is the cause of fast-rotting code in C or some Pascals; fortunately Ada95 doesn't allow it and has an elegant and efficient solution for that issue. I'm sure the users are adult enough to find the most appropriate formulations for _their_ problems after some weeks of Ada programming; therefore hiding the availability of modular types _is_ a disservice. If one tells them that the only solution to mask bits is to write 20 lines of records definitions with representation clauses, they won't use Ada at all, simply! Gautier Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` gdemont @ 2000-11-08 0:00 ` Larry Kilgallen 2000-11-09 4:50 ` Robert Dewar 2000-11-09 4:47 ` Robert Dewar 1 sibling, 1 reply; 71+ messages in thread From: Larry Kilgallen @ 2000-11-08 0:00 UTC (permalink / raw) In article <8ubhlh$ejv$1@nnrp1.deja.com>, gdemont@my-deja.com writes: > >> Of course we could give a simple answer involving the >> obvious solution of converting Character'Pos values to >> a modular type and then doing shifts and masks in the >> normal manner, but that would be a disservice. >> >> I see a *lot* of code that is clearly written by C programmers >> and greatly overuses low level bit twiddling techniques that >> are appropriate to C but not to Ada. >> >> If someone simply wants to get a job done in the dirtiest >> possible fashion, and wants someone else to do the work, >> CLA is not the place to expect free help :-) > > I'm not sure that Mr Binetti intends to do dirty things. Nor was anyone else, and there are even points where Ada experts will disagree as to what "dirty" means. The point is to make the discussion more full, and perhaps we will all learn about an environment where bit masking is required (such as the stream cipher case alluded to by John English). Perhaps we will learn that careful type declaration will "totally solve" the problem at hand. Or perhaps we will learn something unanticipated. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Larry Kilgallen @ 2000-11-09 4:50 ` Robert Dewar 2000-11-10 0:00 ` Lao Xiao Hai 0 siblings, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-09 4:50 UTC (permalink / raw) In article <fEMfmNb1Un8J@eisner.decus.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote: > The point is to make the discussion more full, and perhaps we > will all learn about an environment where bit masking is > required (such as the stream cipher case alluded to by John > English). > Perhaps we will learn that careful type declaration will > "totally solve" the problem at hand. Or perhaps we will learn > something unanticipated. Very nicely put! Indeed the point here is to learn as much about the problem as possible, so that the solution space can be explored in the most effective manner. La > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 4:50 ` Robert Dewar @ 2000-11-10 0:00 ` Lao Xiao Hai 0 siblings, 0 replies; 71+ messages in thread From: Lao Xiao Hai @ 2000-11-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Very nicely put! Indeed the point here is to learn as much > about the problem as possible, so that the solution space can > be explored in the most effective manner. As you have pointed out many times Robert, Ada was never intended to be a convenient language for writing programs. It is more intended for responsibly communicating the intended goal of the program with the fewest errors. Ease of writing gives way to ease of reading. Ada is designed so most constructs are, by default, safe. Therefore, many convenient idioms common to less rigorous languages such as automatic type conversion, automatic promoting of a type, no checking at all on the mode or type of a parameter, etc., are avoided by Ada. On the other hand, it is quite possible to take a language in which the default for every construct is safe and relax the default to less safe. It is not as easy when the default is unsafe (e.g., C and, to a somewhat lesser extent, C++) to override that and make the code more safe. Bit manipulation is simply not that difficult in Ada. And it does not even require overrding the default safety of the language, especially in Ada 95. As has been noted in other postings, even Ada 83 provided straightforward solutions to this, albeit with the requirement that one abide by the rules of the language and make absolutely clear that what is being coded is exactly what is intended. Richard Riehle ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` gdemont 2000-11-08 0:00 ` Larry Kilgallen @ 2000-11-09 4:47 ` Robert Dewar 2000-11-09 0:00 ` gdemont 1 sibling, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-09 4:47 UTC (permalink / raw) In article <8ubhlh$ejv$1@nnrp1.deja.com>, gdemont@my-deja.com wrote: > I'm sure the users are adult enough to find the most appropriate > formulations for _their_ problems after some weeks of Ada > programming; therefore hiding the availability of modular types > _is_ a disservice. I simply disagree, I am talking about lots of code that I see written by professional programmers who do not understand how to do things in Ada. One of the functions of CLA should be to try to show people how things are done in Ada. The idea that being an adult guarantees that people know what they are doing, and that they know the right semantic level to frame their questions at, is misguided. In fact it is often VERY difficult to know what semantic level to frame a question at to get the right answer. The point is that modular types are occasionally, but only occasionally the right way of doing things in Ada. C programmers are used to using this low level approach all the time, because they do not have alternatives (actually even in C, I find that programmers often do not use bitfield specs, simply because they don't know this valuable feature of the C language). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-09 4:47 ` Robert Dewar @ 2000-11-09 0:00 ` gdemont 0 siblings, 0 replies; 71+ messages in thread From: gdemont @ 2000-11-09 0:00 UTC (permalink / raw) > > programming; therefore hiding the availability of modular > types > > _is_ a disservice. > > I simply disagree, I am talking about lots of code that I > see written by professional programmers who do not understand > how to do things in Ada. One of the functions of CLA should > be to try to show people how things are done in Ada. The best way would be to write that there are such and such ways, and, as you wrote, ask for details about the problem to implement. Of course, also say that such method is safer than such one which is maybe faster to program. But concealing a feature for moral reasons is a big disservice to the language, doubly: 1) it make believe (here) that C is necessary for low-level elementary operations; 2) the interfacing is always fragile and make ask: "finally, why did we code the rest in Ada ?". > The idea that being an adult guarantees that people know > what they are doing, and that they know the right semantic > level to frame their questions at, is misguided. I did not mean that if they are adults, they are good programmers. Simply, a mediocre programming will be at least much more reliable (if not safe) in Ada. In various Ada forums/lists, I see sometimes a part of code coming even from "safety-critical" area, where the guy believes that a feature (typically modular types) doesn't exist in Ada, then uses unchecked_conversion on pointers and/or a complicated interface with a "@a#$s++{--x;{}}" - like piece of C. In addition, the code doesn't work and the guy concludes that Ada is really useless (instead of seeing that _he_ is hopeless ;-). G. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-08 0:00 ` Robert Dewar 2000-11-08 0:00 ` Sandro Binetti 2000-11-08 0:00 ` gdemont @ 2000-11-11 0:00 ` Redryder 2000-11-11 0:00 ` Jeff Carter 2000-11-13 0:00 ` Lutz Donnerhacke 2 siblings, 2 replies; 71+ messages in thread From: Redryder @ 2000-11-11 0:00 UTC (permalink / raw) Hey, I have another question concerning bit manipulation. I need to swap the bits in a 32-bit word. I used a packed boolean array. It works well enough, but it does require looping over the array indices. Is there a better way to do this? Oh, I've framed the task correctly! This is in a serial message that goes to a "legacy" system requiring that the bits are swapped. I have more than 40 different messages each having similar bit fields in the message. Still, the bit fields are not the same width or position from message to message. There are a number of them that change position and meaning. I've been using Ada for a year or so now. I was using C/C++. Personally, if you are looking for safe code, I think Ada95 is a good answer. John ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-11 0:00 ` Redryder @ 2000-11-11 0:00 ` Jeff Carter 2000-11-11 0:00 ` Redryder 2000-11-13 0:00 ` Lutz Donnerhacke 1 sibling, 1 reply; 71+ messages in thread From: Jeff Carter @ 2000-11-11 0:00 UTC (permalink / raw) Redryder wrote: > > I need to swap the bits in a 32-bit word. I could perhaps be of more assistance if I knew what you mean by "swap the bits". -- Jeff Carter "I unclog my nose towards you." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-11 0:00 ` Jeff Carter @ 2000-11-11 0:00 ` Redryder 2000-11-12 2:07 ` Ken Garlington 2000-11-12 5:56 ` Jeff Carter 0 siblings, 2 replies; 71+ messages in thread From: Redryder @ 2000-11-11 0:00 UTC (permalink / raw) Jeff, It goes like this: BIT 0 to BIT 31, BIT 31 to BIT 0 , and so on. John Jeff Carter wrote: > Redryder wrote: > > > > I need to swap the bits in a 32-bit word. > > I could perhaps be of more assistance if I knew what you mean by "swap > the bits". > > -- > Jeff Carter > "I unclog my nose towards you." > Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-11 0:00 ` Redryder @ 2000-11-12 2:07 ` Ken Garlington 2000-11-12 5:56 ` Jeff Carter 1 sibling, 0 replies; 71+ messages in thread From: Ken Garlington @ 2000-11-12 2:07 UTC (permalink / raw) As I recall, there was also an implied desire to avoid a loop. How about: package Word_Bitstring is type Object is array (1 .. 32) of Boolean; pragma Pack(Object); function Swap (O : Object) return Object; end Word_Bitstring; package body Word_Bitstring is function Swap (O : Object) return Object is begin return O(32) & O(31) & O(30) & O(29) & O(28) & O(27) & O(26) & O(25) & O(24) & O(23) & O(22) & O(21) & O(20) & O(19) & O(18) & O(17) & O(16) & O(15) & O(14) & O(13) & O(12) & O(11) & O(10) & O(09) & O(08) & O(07) & O(06) & O(05) & O(04) & O(03) & O(02) & O(01); end Swap; end Word_Bitstring; Seems a little error prone, but it might be reasonably efficient. Try it and see! "Redryder" <john.f.anderson@mindspring.com> wrote in message news:3A0DF35D.729DDE15@mindspring.com... : Jeff, : It goes like this: BIT 0 to BIT 31, BIT 31 to BIT 0 , and so on. : John : : Jeff Carter wrote: : : > Redryder wrote: : > > : > > I need to swap the bits in a 32-bit word. : > : > I could perhaps be of more assistance if I knew what you mean by "swap : > the bits". : > : > -- : > Jeff Carter : > "I unclog my nose towards you." : > Monty Python & the Holy Grail : ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-11 0:00 ` Redryder 2000-11-12 2:07 ` Ken Garlington @ 2000-11-12 5:56 ` Jeff Carter 2000-11-12 0:00 ` Robert Dewar 2000-11-12 6:40 ` tmoran 1 sibling, 2 replies; 71+ messages in thread From: Jeff Carter @ 2000-11-12 5:56 UTC (permalink / raw) Redryder wrote: > > It goes like this: BIT 0 to BIT 31, BIT 31 to BIT 0 , and so on. I take it you want the resulting bit pattern to be the reverse of the original bit pattern. This is perhaps best accomplished with packed Boolean arrays, as you can easily manipulate the individual bits directly, and can change 2 bits for each value of the loop index. The fastest but most space-consuming solution would use a look-up table. Few implementations will support an array of the required size. You could also use modular types and operations, but this would probably be less clear than packed Boolean arrays. -- Jeff Carter "I unclog my nose towards you." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-12 5:56 ` Jeff Carter @ 2000-11-12 0:00 ` Robert Dewar 2000-11-12 0:00 ` tmoran 2000-11-12 6:40 ` tmoran 1 sibling, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-12 0:00 UTC (permalink / raw) In article <3A0E3116.83AEC906@acm.org>, Jeff Carter <jrcarter@acm.org> wrote: > The fastest but most space-consuming solution would use a > look-up table. Few implementations will support an array of > the required size. You obviously cannot afford a loop through 32 bits, that's a gruesomely inefficient implementation. The proper thing is to establish a look up table of 256 entries (that takes up only 256 bytes and easily fits into primary cache). Then program the byte swap (if you are on a machine with a byte swap instruction like the Power PC, it can be used directly). If you have a bit more space, you can make a table of 64K 16-bit entries and do 16-bit swaps by table lookup. That still takes only 128K bytes, which can easily fit in secondary cache. Even if you could afford a table of 16 gigabytes for the full lookup, you would not want to use such an approach, since you would get cache misses, and probably TLB misses as well on every access, and it would be horribly slow. You just HAVE to be sensitive to cache and TLB-miss issues in modern programming if performance is an issue. Far too many people have not adjusted their thinking and are still programming for non-pipelined non-cached machines in their minds :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-12 0:00 ` Robert Dewar @ 2000-11-12 0:00 ` tmoran 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:54 ` Ken Garlington 0 siblings, 2 replies; 71+ messages in thread From: tmoran @ 2000-11-12 0:00 UTC (permalink / raw) >You just HAVE to be sensitive to cache and TLB-miss issues >in modern programming if performance is an issue. Far too At what point in a programmer's education is this taught these days? ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-12 0:00 ` tmoran @ 2000-11-13 0:00 ` Robert Dewar 2000-11-14 0:00 ` Marc A. Criley 2000-11-13 0:54 ` Ken Garlington 1 sibling, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-13 0:00 UTC (permalink / raw) In article <rwDP5.415395$i5.7092109@news1.frmt1.sfba.home.com>, tmoran@acm.org wrote: > >You just HAVE to be sensitive to cache and TLB-miss issues > >in modern programming if performance is an issue. Far too > At what point in a programmer's education is this taught > these days? Hard to say, since things are very variable. All too often the answer is not at all. At NYU, we used to have the whole second year be assembly language programming and machine and system architecture. But the faculty found that too much, and it was cut to one semester. Quite a few folks on the NYU faculty would like to cut out that remaining semester as a required course, and make it an elective on the grounds that most people don't need to know low level stuff, and I am afraid that viewpoint (which I strongly object to) has already found favor at many major universities, and people can get an undergraduate degree without this material ever being taught. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Robert Dewar @ 2000-11-14 0:00 ` Marc A. Criley 0 siblings, 0 replies; 71+ messages in thread From: Marc A. Criley @ 2000-11-14 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <rwDP5.415395$i5.7092109@news1.frmt1.sfba.home.com>, > tmoran@acm.org wrote: > > >You just HAVE to be sensitive to cache and TLB-miss issues > > >in modern programming if performance is an issue. Far too > > At what point in a programmer's education is this taught > > these days? > > Hard to say, since things are very variable. All too often > the answer is not at all. At NYU, we used to have the whole > second year be assembly language programming and machine > and system architecture. But the faculty found that too > much, and it was cut to one semester. Quite a few folks > on the NYU faculty would like to cut out that remaining > semester as a required course, and make it an elective on > the grounds that most people don't need to know low level > stuff, and I am afraid that viewpoint (which I strongly > object to) has already found favor at many major universities, > and people can get an undergraduate degree without this > material ever being taught. > I certainly must concur with the opposition to that viewpoint. On many occasions over the course of my career I've had the debugger display raw memory, registers, and assembly language to assist the uncovering of bugs. And all too frequently when working with someone else, I find that pulling up these displays to look at low-level information leaves them glassy eyed and bewildered. They have little cognizance of what's going on beneath the surface of the software, be it C, C++, or Ada. Marc A. Criley Senior Staff Engineer Quadrus Corporation ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-12 0:00 ` tmoran 2000-11-13 0:00 ` Robert Dewar @ 2000-11-13 0:54 ` Ken Garlington 1 sibling, 0 replies; 71+ messages in thread From: Ken Garlington @ 2000-11-13 0:54 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:rwDP5.415395$i5.7092109@news1.frmt1.sfba.home.com... : >You just HAVE to be sensitive to cache and TLB-miss issues : >in modern programming if performance is an issue. Far too : At what point in a programmer's education is this taught these days? Well, at the University of Texas at Arlington, it's taught as part of a graduate course in computer architecture. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-12 5:56 ` Jeff Carter 2000-11-12 0:00 ` Robert Dewar @ 2000-11-12 6:40 ` tmoran 1 sibling, 0 replies; 71+ messages in thread From: tmoran @ 2000-11-12 6:40 UTC (permalink / raw) >I take it you want the resulting bit pattern to be the reverse of the >original bit pattern. >... >The fastest but most space-consuming solution would use a look-up table. Swap parts and use a lookup table to swap bits within those parts, eg: type Bytes is mod 256; type Reversibles is array(1 .. 4) of Bytes; Xlate : constant array(Bytes) of Bytes := (16#00000000#,16#10000000#,16#01000000#,16#11000000#, 16#00100000#,16#10100000#,16#01100000#,16#11100000#, 16#00010000#,16#10010000#,16#01010000#,16#11010000#, 16#00110000#,16#10110000#,16#01110000#,16#11110000#, 16#00001000#,16#10001000#,16#01001000#,16#11001000#, 16#00101000#,16#10101000#,16#01101000#,16#11101000#, 16#00011000#,16#10011000#,16#01011000#,16#11011000#, 16#00111000#,16#10111000#,16#01111000#,16#11111000#, 16#00000100#,16#10000100#,16#01000100#,16#11000100#, 16#00100100#,16#10100100#,16#01100100#,16#11100100#, 16#00010100#,16#10010100#,16#01010100#,16#11010100#, 16#00110100#,16#10110100#,16#01110100#,16#11110100#, 16#00001100#,16#10001100#,16#01001100#,16#11001100#, 16#00101100#,16#10101100#,16#01101100#,16#11101100#, 16#00011100#,16#10011100#,16#01011100#,16#11011100#, 16#00111100#,16#10111100#,16#01111100#,16#11111100#, 16#00000010#,16#10000010#,16#01000010#,16#11000010#, 16#00100010#,16#10100010#,16#01100010#,16#11100010#, 16#00010010#,16#10010010#,16#01010010#,16#11010010#, 16#00110010#,16#10110010#,16#01110010#,16#11110010#, 16#00001010#,16#10001010#,16#01001010#,16#11001010#, 16#00101010#,16#10101010#,16#01101010#,16#11101010#, 16#00011010#,16#10011010#,16#01011010#,16#11011010#, 16#00111010#,16#10111010#,16#01111010#,16#11111010#, 16#00000110#,16#10000110#,16#01000110#,16#11000110#, 16#00100110#,16#10100110#,16#01100110#,16#11100110#, 16#00010110#,16#10010110#,16#01010110#,16#11010110#, 16#00110110#,16#10110110#,16#01110110#,16#11110110#, 16#00001110#,16#10001110#,16#01001110#,16#11001110#, 16#00101110#,16#10101110#,16#01101110#,16#11101110#, 16#00011110#,16#10011110#,16#01011110#,16#11011110#, 16#00111110#,16#10111110#,16#01111110#,16#11111110#, 16#00000001#,16#10000001#,16#01000001#,16#11000001#, 16#00100001#,16#10100001#,16#01100001#,16#11100001#, 16#00010001#,16#10010001#,16#01010001#,16#11010001#, 16#00110001#,16#10110001#,16#01110001#,16#11110001#, 16#00001001#,16#10001001#,16#01001001#,16#11001001#, 16#00101001#,16#10101001#,16#01101001#,16#11101001#, 16#00011001#,16#10011001#,16#01011001#,16#11011001#, 16#00111001#,16#10111001#,16#01111001#,16#11111001#, 16#00000101#,16#10000101#,16#01000101#,16#11000101#, 16#00100101#,16#10100101#,16#01100101#,16#11100101#, 16#00010101#,16#10010101#,16#01010101#,16#11010101#, 16#00110101#,16#10110101#,16#01110101#,16#11110101#, 16#00001101#,16#10001101#,16#01001101#,16#11001101#, 16#00101101#,16#10101101#,16#01101101#,16#11101101#, 16#00011101#,16#10011101#,16#01011101#,16#11011101#, 16#00111101#,16#10111101#,16#01111101#,16#11111101#, 16#00000011#,16#10000011#,16#01000011#,16#11000011#, 16#00100011#,16#10100011#,16#01100011#,16#11100011#, 16#00010011#,16#10010011#,16#01010011#,16#11010011#, 16#00110011#,16#10110011#,16#01110011#,16#11110011#, 16#00001011#,16#10001011#,16#01001011#,16#11001011#, 16#00101011#,16#10101011#,16#01101011#,16#11101011#, 16#00011011#,16#10011011#,16#01011011#,16#11011011#, 16#00111011#,16#10111011#,16#01111011#,16#11111011#, 16#00000111#,16#10000111#,16#01000111#,16#11000111#, 16#00100111#,16#10100111#,16#01100111#,16#11100111#, 16#00010111#,16#10010111#,16#01010111#,16#11010111#, 16#00110111#,16#10110111#,16#01110111#,16#11110111#, 16#00001111#,16#10001111#,16#01001111#,16#11001111#, 16#00101111#,16#10101111#,16#01101111#,16#11101111#, 16#00011111#,16#10011111#,16#01011111#,16#11011111#, 16#00111111#,16#10111111#,16#01111111#,16#11111111#); function Swap (X : REVERSIBLES) return REVERSIBLES is begin return (Xlate(X(4)), Xlate(X(3)), Xlate(X(2)), Xlate(X(1))); end Swap; ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-11 0:00 ` Redryder 2000-11-11 0:00 ` Jeff Carter @ 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Robert Dewar 1 sibling, 2 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-13 0:00 UTC (permalink / raw) * Redryder wrote: >I need to swap the bits in a 32-bit word. type word32 is 0 .. 2**32-1; procedure swap32 (i : in word32) returns word32 is type lowrec is record data : word32; end record; type highrec is record data : word32; end record; for lowrec'Bit_Order use Low_Order_First; for highrec'Bit_Order use High_Order_First; function l2h is new Ada.Unchecked_Conversion (lowrec, highrec); low : lowrec := (i); high : highrec := l2h(low); begin return high; end swap32; It's up to your compiler to find out what's a effictive way to implement this. Some architectures may use the endianess swap prefix opcode. \f Other question: GNAT 3.12p has problems with efficent code of a simple rotation. How to solve it portable? with Ada.Unchecked_Conversion; procedure binary_rotation is wordsize : constant := 16; type word is mod 2**wordsize; type bitfield is array(1..wordsize) of boolean; pragma Pack(bitfield); -- the following clause will not work without pragma for bitfield'Size use wordsize; function w2b is new Ada.Unchecked_Conversion (word, bitfield); function b2w is new Ada.Unchecked_Conversion (bitfield, word); subtype offset is Natural range 1 .. wordsize-1; function rotate (b : bitfield; s : offset) return bitfield is begin return b(b'first .. b'last - s) & b(b'last - s + 1 .. b'last); end rotate; begin null; end binary_rotation; ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Lutz Donnerhacke @ 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 1 sibling, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-13 0:00 UTC (permalink / raw) In article <slrn90vl0k.l5.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > pragma Pack(bitfield); -- the following clause will not work > -- without pragma > for bitfield'Size use wordsize; As most certainly you would expect, see RM 13.3: 53 A Size clause on a composite subtype should not affect the internal layout of components. followed by some gruesome code for doing a rotate, to which one must ask, why on earth not use the Rotate functions provided as primitives in Ada 95 (these can be located by looking up the keyword rotate in the index!) Yes, I suppose GNAT (or in general any Ada 95 compiler) could try to optimize this gruesome code, but since no one would ever write it anyway, why bother? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Robert Dewar @ 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-13 0:00 UTC (permalink / raw) * Robert Dewar wrote: > lutz@iks-jena.de (Lutz Donnerhacke) wrote: >> pragma Pack(bitfield); -- the following clause will not work >> -- without pragma >> for bitfield'Size use wordsize; > >As most certainly you would expect, see RM 13.3: > > 53 A Size clause on a composite subtype should not affect > the internal layout of components. Thanx. I noticed it some weeks before and missed to remove the comment. >followed by some gruesome code for doing a rotate, to which one must ask, >why on earth not use the Rotate functions provided as primitives in Ada 95 >(these can be located by looking up the keyword rotate in the index!) This piece of code is from my play and experimental grounds. I'd prefer a portable solution instead of mapping maschine code into a portability lib. Not all bit manipulation actions provided by the underlying CPU can be expeced to occur as compiler directives. This becomes especially true, if some complex manipulations has to be done. >Yes, I suppose GNAT (or in general any Ada 95 compiler) could try to >optimize this gruesome code, but since no one would ever write it anyway, >why bother? Because the generated code is even worse. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Lutz Donnerhacke @ 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 0 siblings, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-13 0:00 UTC (permalink / raw) In article <slrn90vsv1.l5.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > This piece of code is from my play and experimental grounds. > I'd prefer a portable solution instead of mapping maschine > code into a portability lib. No no no! Rotate_Left is a function defined IN THE ADA 95 RM, it is a high level function that is defined at the Ada semantic level. Yes, it will translate to some efficient sequence of machine instructions (a single rotate instruction, where such exists, some equivalent clever sequence where it does not). There is absolutely NO need EVER to do roll-your-own rotates in Ada 95. As I say, this is not exactly obscure, if you look up rotate in the RM index, you will find the reference. One note here. In the RM, Rotate_Left and Rotate_Right are defined only on the types in Interfaces, which is a bit limiting, but for portability across compilers you have to stick to this. In GNAT, we permit the definition of an intrinsic (using pragma Import (Intrinsic,Rotate_xxx)) Rotate_Left/Right for any user defined modular type, but this is not necessarily portable (this is actually something the ARG should add as a recommended enhancement, since it is hard to imagine any compiler would find it hard to do). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Robert Dewar @ 2000-11-13 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-13 0:00 UTC (permalink / raw) * Robert Dewar wrote: >lutz@iks-jena.de (Lutz Donnerhacke) wrote: >> This piece of code is from my play and experimental grounds. >> I'd prefer a portable solution instead of mapping maschine >> code into a portability lib. > >No no no! Rotate_Left is a function defined IN THE ADA 95 RM, Yes. In B.2. I found a obscure definition in the MD5 packet, so I did not read the RM. My fault. Sorry. >There is absolutely NO need EVER to do roll-your-own rotates >in Ada 95. Rotation was a simple example for my limited mind to play with. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar @ 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 1 sibling, 1 reply; 71+ messages in thread From: Robert Dewar @ 2000-11-13 0:00 UTC (permalink / raw) In article <slrn90vl0k.l5.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > * Redryder wrote: > >I need to swap the bits in a 32-bit word. > > type word32 is 0 .. 2**32-1; > > procedure swap32 (i : in word32) returns word32 is > type lowrec is record data : word32; end record; > type highrec is record data : word32; end record; > for lowrec'Bit_Order use Low_Order_First; > for highrec'Bit_Order use High_Order_First; > > function l2h is new Ada.Unchecked_Conversion (lowrec, highrec); > > low : lowrec := (i); > high : highrec := l2h(low); > begin > return high; > end swap32; > > It's up to your compiler to find out what's a effictive way to > implement this. No, this is completely wrong. Once again, it is *really* a good idea to actually try out something before posting it here. Bit_Order confuses many people, since certainly it *sounds* as though it might do what you expected, but most certainly it does *not* do anything of the kind. In fact the solution above is doubly wrong, because the use of unchecked conversion ensures that nothing actually happens at all! You clearly did not compile the code, or you would have seen other errors as follows: 1. procedure when you meant function 2. returns when you meant return 3. positional aggregate with only one component 4. wrong return type All in all, these few lines of code contain a rather high density of errors, and certainly do not inform this discussion. It does not take much effort to try out any code you post. I always do, because even for a simple program, I do not trust myself to avoid silly mistakes :-) In any case, read the GNAT documentation to understand what the real situation here is. The operable sentence from the GNAT Reference Manual is In the case where the non-standard value is specified, the effect is to renumber bits within each bit, but the ordering of bytes is not affected. let alone ordering of bits!!!! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Robert Dewar @ 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-13 0:00 UTC (permalink / raw) * Robert Dewar wrote: > lutz@iks-jena.de (Lutz Donnerhacke) wrote: >> for lowrec'Bit_Order use Low_Order_First; >> for highrec'Bit_Order use High_Order_First; >> >> function l2h is new Ada.Unchecked_Conversion (lowrec, highrec); >No, this is completely wrong. Once again, it is *really* a good >idea to actually try out something before posting it here. GNAT can not compile it. Bit_Order can not be set. >Bit_Order confuses many people, since certainly it *sounds* >as though it might do what you expected, but most certainly >it does *not* do anything of the kind. Very bad. I would offer a perfect way to use the representation clauses for real world applications. But so they are nearly senseless. >In fact the solution above is doubly wrong, because the use of unchecked >conversion ensures that nothing actually happens at all! Sure? The return statment (with was wrong, because .data was forgotten) would generate a endianess prefix on reading the memory location. This does the whole thing. (Using Alpha, Ia64, ...) >In any case, read the GNAT documentation to understand what the real >situation here is. The operable sentence from the GNAT Reference Manual is > > In the case where the non-standard value is specified, the > effect is to renumber bits within each bit, but the ordering > of bytes is not affected. > >let alone ordering of bits!!!! We talk about bit ordering. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Lutz Donnerhacke @ 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-20 0:00 ` Randy Brukardt 0 siblings, 2 replies; 71+ messages in thread From: Robert Dewar @ 2000-11-13 0:00 UTC (permalink / raw) In article <slrn90vt78.l5.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) wrote: > GNAT can not compile it. Bit_Order can not be set. That is incorrect, as of version 3.13, GNAT implements the capability of setting Bit_Order in situations where this makes sense, including this one. > >Bit_Order confuses many people, since certainly it *sounds* > >as though it might do what you expected, but most certainly > >it does *not* do anything of the kind. > > Very bad. I would offer a perfect way to use the > representation clauses for > real world applications. But so they are nearly senseless. Not at all! Setting Bit_Order is quite valuable for some situations of endian independence. You are just confused about the purpose and semantics of this capability. The fact that it does not do what you want it to do does not make it senseless! A typical useful application is to specify the position of bits within a single byte as 8 record componens in a manner that is endian-independent. > >In fact the solution above is doubly wrong, because the use > >of unchecked > >conversion ensures that nothing actually happens at all! > > Sure? The return statment (with was wrong, because .data was > forgotten) > would generate a endianess prefix on reading the memory > location. This does the whole thing. (Using Alpha, Ia64, ...) Not evan vaguely. Like many people you are confusing byte endianness with bit order. I would recommend reading the section in my book on Microprocessors on this subject which is at least an attempt to sort this out. Note that a lot of people, including the designers and documenters of the 68K got confused on this issue. > >In any case, read the GNAT documentation to understand what the real > >situation here is. The operable sentence from the GNAT Reference Manual is > > > > In the case where the non-standard value is specified, the > > effect is to renumber bits within each bit, but the ordering > > of bytes is not affected. > > > >let alone ordering of bits!!!! > > We talk about bit ordering. We do indeed! The Bit_Order attribute in Ada talks ONLY about numbering of the bits, it does NOT provide a facility for reversing bits AT ALL! So that is why you should read the documentation carefully. Norman Cohen has also written a useful piece on Bit_Order, it is in one of the relevant AI's. Perhaps someone can give the reference. By the way, we find that helping people through the porting problems associated with switching endianness is a very common activity in our support efforts. One even has to wonder if the original questioner *really* wants to do what he says he wants to do. In my experience, most people who want to reverse bits, don't really want to, they are confused in the same way that Lutz was confused into thinking that endianness switching involves bit-reversal. of course there are legitimate requirements for bit order swaps in the communications area, but you have to wonder .... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Robert Dewar @ 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Pat Rogers 2000-11-14 0:00 ` Martin Dowie 2000-11-20 0:00 ` Randy Brukardt 1 sibling, 2 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-13 0:00 UTC (permalink / raw) * Robert Dewar wrote: > lutz@iks-jena.de (Lutz Donnerhacke) wrote: >> GNAT can not compile it. Bit_Order can not be set. > >That is incorrect, as of version 3.13, GNAT implements the capability of >setting Bit_Order in situations where this makes sense, including this >one. Great. I found the announcement (it was posted while I was unable to access any computer) >Not at all! Setting Bit_Order is quite valuable for some situations of >endian independence. You are just confused about the purpose and semantics >of this capability. The fact that it does not do what you want it to do >does not make it senseless! >A typical useful application is to specify the position of bits within a >single byte as 8 record componens in a manner that is endian-independent. This would ease one of my programming issues. Fine. >Not evan vaguely. Like many people you are confusing byte endianness with >bit order. I see your point. So word8 can only be used: with Ada.Unchecked_Conversion; with System; procedure endian is type word8 is mod 2**8; type word32 is mod 2**32; type composite is array (1..4) of word8; pragma Pack(composite); type lowrec is record val: composite; end record; type highrec is record val: composite; end record; for lowrec'Bit_Order use System.Low_Order_First; for highrec'Bit_Order use System.High_Order_First; function w32tohigh is new Ada.Unchecked_Conversion(word32, highrec); function lowtow32 is new Ada.Unchecked_Conversion(lowrec, word32); function h2l32 (h : word32) return word32 is hr : highrec := w32tohigh (h); lr : lowrec; begin lr.val(1) := hr.val(4); lr.val(2) := hr.val(3); lr.val(3) := hr.val(2); lr.val(4) := hr.val(1); return lowtow32 (lr); end h2l32; begin null; end endian; >I would recommend reading the section in my book on Microprocessors on >this subject which is at least an attempt to sort this out. Google did not came back with an URL. May I ask for a hint? >We do indeed! The Bit_Order attribute in Ada talks ONLY about numbering of >the bits, it does NOT provide a facility for reversing bits AT ALL! Yep. I read the passage, but was unable to understand it correctly. >So that is why you should read the documentation carefully. Norman Cohen >has also written a useful piece on Bit_Order, it is in one of the relevant >AI's. Perhaps someone can give the reference. URL? Google is very quite on this keywords, too. >One even has to wonder if the original questioner *really* wants to do >what he says he wants to do. In my experience, most people who want to >reverse bits, don't really want to, they are confused in the same way that >Lutz was confused into thinking that endianness switching involves >bit-reversal. >of course there are legitimate requirements for bit order swaps in the >communications area, but you have to wonder .... Can I use GNAT 3.13 to work with Token Ring MACs ;-) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Lutz Donnerhacke @ 2000-11-13 0:00 ` Pat Rogers 2000-11-13 0:00 ` Brian Rogoff 2000-11-14 0:00 ` Martin Dowie 1 sibling, 1 reply; 71+ messages in thread From: Pat Rogers @ 2000-11-13 0:00 UTC (permalink / raw) "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message news:slrn9104p4.l5.lutz@taranis.iks-jena.de... > * Robert Dewar wrote: <snip> > >I would recommend reading the section in my book on Microprocessors on > >this subject which is at least an attempt to sort this out. > > Google did not came back with an URL. May I ask for a hint? R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View: McGraw-Hill, 1990. ISBN for the hardback version is 0-07-016639-0 Still good reading. --- Patrick Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Pat Rogers @ 2000-11-13 0:00 ` Brian Rogoff 2000-11-13 0:00 ` F. Britt Snodgrass ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Brian Rogoff @ 2000-11-13 0:00 UTC (permalink / raw) On Mon, 13 Nov 2000, Pat Rogers wrote: > "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message > > Google did not came back with an URL. May I ask for a hint? > > R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View: > McGraw-Hill, 1990. ISBN for the hardback version is 0-07-016639-0 > > Still good reading. It's out of print, and isn't even in many libraries, so while it may be a great book it's a bit unfair to suggest it as a reference. I tried to order it about a year or so ago and it was OOP then so this isn't new news. Any chance for a second edition? A web version (like Grune's parsing textbook), or even class notes? Barring that, how about suggesting a reference that people can actually get without incredible effort? :-) -- Brian ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Brian Rogoff @ 2000-11-13 0:00 ` F. Britt Snodgrass 2000-11-15 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Pat Rogers 2000-11-14 0:00 ` Georg Bauhaus 2 siblings, 1 reply; 71+ messages in thread From: F. Britt Snodgrass @ 2000-11-13 0:00 UTC (permalink / raw) I found and bought my copy last year through http:/www.abebooks.com. There is apparently one copy now available at http://dogbert.abebooks.com/abe/BookDetails?bi=84214139 Britt Brian Rogoff wrote: > > On Mon, 13 Nov 2000, Pat Rogers wrote: > > "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message > > > Google did not came back with an URL. May I ask for a hint? > > > > R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View: > > McGraw-Hill, 1990. ISBN for the hardback version is 0-07-016639-0 > > > > Still good reading. > > It's out of print, and isn't even in many libraries, so while it may be a > great book it's a bit unfair to suggest it as a reference. > > I tried to order it about a year or so ago and it was OOP then so this > isn't new news. > > Any chance for a second edition? A web version (like Grune's parsing > textbook), or even class notes? Barring that, how about suggesting a > reference that people can actually get without incredible effort? :-) > > -- Brian ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` F. Britt Snodgrass @ 2000-11-15 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-15 0:00 UTC (permalink / raw) * F. Britt Snodgrass wrote: >http://dogbert.abebooks.com/abe/BookDetails?bi=84214139 "A book that is now unavailable has been removed from your basket." Thx anyway. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Brian Rogoff 2000-11-13 0:00 ` F. Britt Snodgrass @ 2000-11-13 0:00 ` Pat Rogers 2000-11-14 0:00 ` Georg Bauhaus 2 siblings, 0 replies; 71+ messages in thread From: Pat Rogers @ 2000-11-13 0:00 UTC (permalink / raw) "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message news:Pine.BSF.4.21.0011131126360.7789-100000@shell5.ba.best.com... > On Mon, 13 Nov 2000, Pat Rogers wrote: > > "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message > > > Google did not came back with an URL. May I ask for a hint? > > > > R. B. K. Dewar and M. Smosna, Microprocessors: A Programmer's View: > > McGraw-Hill, 1990. ISBN for the hardback version is 0-07-016639-0 > > > > Still good reading. > > It's out of print, and isn't even in many libraries, so while it may be a > great book it's a bit unfair to suggest it as a reference. > > I tried to order it about a year or so ago and it was OOP then so this > isn't new news. > > Any chance for a second edition? A web version (like Grune's parsing > textbook), or even class notes? Barring that, how about suggesting a > reference that people can actually get without incredible effort? :-) I don't quite understand the above. Are you suggesting I keep track of whether or not all the books I own are still in print or are available in libraries? :-) He asked for more info so I gave it to him. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Brian Rogoff 2000-11-13 0:00 ` F. Britt Snodgrass 2000-11-13 0:00 ` Pat Rogers @ 2000-11-14 0:00 ` Georg Bauhaus 2000-11-15 0:00 ` Lutz Donnerhacke 2 siblings, 1 reply; 71+ messages in thread From: Georg Bauhaus @ 2000-11-14 0:00 UTC (permalink / raw) Brian Rogoff (bpr@shell5.ba.best.com) wrote: : [Dewar/Smosna: Microprocessors] : Any chance for a second edition? iirc, Mr. Dewar said "in the making" some months(?) ago, here in c.l.a. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-14 0:00 ` Georg Bauhaus @ 2000-11-15 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-15 0:00 UTC (permalink / raw) * Georg Bauhaus wrote: >Brian Rogoff (bpr@shell5.ba.best.com) wrote: >: [Dewar/Smosna: Microprocessors] >: Any chance for a second edition? > >iirc, Mr. Dewar said "in the making" some months(?) ago, here >in c.l.a. Great. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Pat Rogers @ 2000-11-14 0:00 ` Martin Dowie 2000-11-15 0:00 ` Lutz Donnerhacke 1 sibling, 1 reply; 71+ messages in thread From: Martin Dowie @ 2000-11-14 0:00 UTC (permalink / raw) er, you realize that the "'Bit_Order" here is unnecessary? try it - it will make no difference if you comment them out (or make them the same) as they simply provide a way of referencing bits (i.e. High_Order_First = bit(0)MSB, Low_Order_First = bit(0)LSB) and you don't reference any bit positions! What you have tried to acheive by the use of 'Bit_Order, you have done by actually doing the assignments. 'Bit_Order played no part. Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:slrn9104p4.l5.lutz@taranis.iks-jena.de... [snip] > with Ada.Unchecked_Conversion; > with System; > > procedure endian is > type word8 is mod 2**8; > type word32 is mod 2**32; > type composite is array (1..4) of word8; > pragma Pack(composite); > > type lowrec is record val: composite; end record; > type highrec is record val: composite; end record; > for lowrec'Bit_Order use System.Low_Order_First; > for highrec'Bit_Order use System.High_Order_First; > > function w32tohigh is new Ada.Unchecked_Conversion(word32, highrec); > function lowtow32 is new Ada.Unchecked_Conversion(lowrec, word32); > > function h2l32 (h : word32) return word32 is > hr : highrec := w32tohigh (h); > lr : lowrec; > begin > lr.val(1) := hr.val(4); > lr.val(2) := hr.val(3); > lr.val(3) := hr.val(2); > lr.val(4) := hr.val(1); > return lowtow32 (lr); > end h2l32; > begin > null; > end endian; ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-14 0:00 ` Martin Dowie @ 2000-11-15 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-15 0:00 UTC (permalink / raw) * Martin Dowie wrote: >er, you realize that the "'Bit_Order" here is unnecessary? try it - it >will make no difference if you comment them out (or make them the >same) as they simply provide a way of referencing bits >(i.e. High_Order_First = bit(0)MSB, Low_Order_First = bit(0)LSB) >and you don't reference any bit positions! Thanx. I still try to understand that subject. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke @ 2000-11-20 0:00 ` Randy Brukardt 2000-11-21 0:00 ` Lutz Donnerhacke 1 sibling, 1 reply; 71+ messages in thread From: Randy Brukardt @ 2000-11-20 0:00 UTC (permalink / raw) Robert Dewar wrote in message <8up1j4$uqe$1@nnrp1.deja.com>... >We do indeed! The Bit_Order attribute in Ada talks ONLY about >numbering of the bits, it does NOT provide a facility for >reversing bits AT ALL! So that is why you should read the >documentation carefully. Norman Cohen has also written a useful >piece on Bit_Order, it is in one of the relevant AI's. Perhaps >someone can give the reference. The Cohen paper is in AI-133. That version is in plain text; there is a better PDF version (in which you can see the diagrams - a big help) available on the ACAA web site in the "grab bag" area. (The ACAA web site is found at www.ada-auth.org/~acats; I can't check the exact URL of the Cohen paper since I'm not connected to the net at the moment. Randy Brukardt (ARG Editor) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-20 0:00 ` Randy Brukardt @ 2000-11-21 0:00 ` Lutz Donnerhacke 2000-11-21 0:00 ` Stephen Leake 0 siblings, 1 reply; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-21 0:00 UTC (permalink / raw) * Randy Brukardt wrote: >The Cohen paper is in AI-133. That version is in plain text; there is a >better PDF version (in which you can see the diagrams - a big help) >available on the ACAA web site in the "grab bag" area. (The ACAA web >site is found at www.ada-auth.org/~acats; I can't check the exact URL of >the Cohen paper since I'm not connected to the net at the moment. http://www.ada-auth.org/~acats/ai-files/grab_bag/bitorder.pdf Great ressource. Thank you. Giving something back to the community (bash scripts to ease development): \f function gm { DEST="$1" if [ -z "$DEST" ]; then for DEST in *adb; do [ -s $(basename "$DEST" b)s ] || break done fi DEST=$(basename "$DEST" .adb) if gnatmake `[-s .gnat_opts] && cat .gnat_opts` "$DEST"; then [ -d html/ -a \( ! -s html/index.htm -o "$DEST" -nt html/index.htm \) ] && gnathtml.pl -f -d "$DEST" fi } function clearall() { for i in *.ad[bs]; do if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".o "$j".ali "b_$j".c "$j".s ?~"$j".ad[bs] fi done for i in *.[hc] *.cpp; do if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".o "$j".s fi done for i in *.tex; do if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".dvi "$j".aux "$j".toc "$j".lo[ftg] rm -fv "$j".glo "$j".idx "$j".ilg "$j".ind "$j".ind.aux fi done for i in *.mf; do if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".dvi "$j".log "$j".[1-9]*gf fi done for i in *.web; do if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$j".p "$j".tex fi done rm -fv *.txt{~,.bak} } -- the \year=2001 TeX calendar; IKS Garamond, 2000; ISBN 3-934601-10-3 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-21 0:00 ` Lutz Donnerhacke @ 2000-11-21 0:00 ` Stephen Leake 2000-11-22 0:00 ` Lutz Donnerhacke 0 siblings, 1 reply; 71+ messages in thread From: Stephen Leake @ 2000-11-21 0:00 UTC (permalink / raw) lutz@iks-jena.de (Lutz Donnerhacke) writes: > Giving something back to the community (bash scripts to ease development): > <snip bash scripts> These scripts may be useful, and they even may be well written. But since there are no comments, and no other descriptions of what they are supposed to do, or why I might want to use them, I can't tell! Bash syntax includes comments; please use them! -- -- Stephe ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-21 0:00 ` Stephen Leake @ 2000-11-22 0:00 ` Lutz Donnerhacke 0 siblings, 0 replies; 71+ messages in thread From: Lutz Donnerhacke @ 2000-11-22 0:00 UTC (permalink / raw) * Stephen Leake wrote: >lutz@iks-jena.de (Lutz Donnerhacke) writes: >> Giving something back to the community (bash scripts to ease development): >> <snip bash scripts> > >These scripts may be useful, and they even may be well written. But >since there are no comments, and no other descriptions of what they >are supposed to do, or why I might want to use them, I can't tell! > >Bash syntax includes comments; please use them! Ok. function clearall() { # unlinks all temporary files can be regenerated for i in *.ad[bs]; do # all Ada source files if [ -s "$i" ]; then # existing ones j="${i%.*}" # remove extension rm -fv "$i"~ "$i".bak "$j".o "$j".ali "b_$j".c "$j".s ?~"$j".ad[bs] fi done for i in *.[hc] *.cpp; do # all C or C++ source files if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".o "$j".s fi done for i in *.tex; do # all TeX or LaTeX sources if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".dvi "$j".aux "$j".toc "$j".lo[ftg] rm -fv "$j".glo "$j".idx "$j".ilg "$j".ind "$j".ind.aux fi done for i in *.mf; do # all METAFONT sources if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$i".bak "$j".dvi "$j".log "$j".[1-9]*gf fi done for i in *.web; do # all Web sources (meta programming/documentation l.) if [ -s "$i" ]; then j="${i%.*}" rm -fv "$i"~ "$j".p "$j".tex fi done rm -fv *.txt{~,.bak} # all editor backups of text files } \f #! /bin/sh DEST="$1" if [ -z "$DEST" ]; then # no argument given => choose best match for DEST in *adb; do # try all files with real work [ -s $(basename "$DEST" b)s ] || break # select those w/o specification done fi DEST=$(basename "$DEST" .adb) # remove extension if gnatmake `[ -s .gnat_opts ] && cat .gnat_opts` "$DEST"; then # Compiles without errors [ -d html/ ] && # there is a documentation directory [ ! -s html/index.htm -o "$DEST" -nt html/index.htm ] && # remake necessary gnathtml.pl -f -d "$DEST" fi -- the \year=2001 TeX calendar; IKS Garamond, 2000; ISBN 3-934601-10-3 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2000-11-07 0:00 ` Larry Kilgallen 2000-11-07 0:00 ` John English 2000-11-08 0:00 ` gdemont @ 2000-11-08 7:18 ` Sandro Binetti 2 siblings, 0 replies; 71+ messages in thread From: Sandro Binetti @ 2000-11-08 7:18 UTC (permalink / raw) In article <2WTH$pdrCfOd@eisner.decus.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote: > Quite often when someone wants to do something like that, they had > formerly programmed in some other language whose ability to define > data types is not so robust as Ada. Ok! I'm a C programmer too. Why do you say "robust"? You can write a "robust" source code even by using other languages than ADA. The matter is not that. In this case I'd say "flexible", instead of "not robust". I always discriminate a data structure in two indipendent points of wiew: 1) the semantic one (the type, of course) 2) the sintactic one (the way the type is stored and internally represented) In some occasion, expecially when you work at low-level device handling, you need to approach the problem by a semantic (logic) way, without forgetting that your "idea" has a peculiar way to be treated on the target hardware (and, so, it can't be completely divided from the sintactic approach). That's to say that, in such an occasion like these, there no need (and no meaning) to split the type from its internal representation: it's only a conceptual overhead! > > Except for the particular situation of changing case of an ASCII > Roman letter (for which Ada95 has built-in capabilities), flipping > a bit in a character is totally meaningless. Are you sure? Can you say there'no situation at all in witch you need to manipulate a seven-bit character, regardless of its ASCII semantic? Have you ever thougth of some encryption-encoding algorithm, based on some perverse actions on a character bit? > > If you really meant to blip a bit in a data cell that happens to > be 8 bits wide, then please study record and array declarations > in an introductory Ada text Done, when I was 18! Thanks a lot for your interest in my "stupid" problem. -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Thank you all for your contribution ! 2000-11-07 0:00 Bit manipulation Sandro Binetti 2000-11-07 0:00 ` gdemont 2000-11-07 0:00 ` Larry Kilgallen @ 2000-11-10 7:24 ` Sandro Binetti 2 siblings, 0 replies; 71+ messages in thread From: Sandro Binetti @ 2000-11-10 7:24 UTC (permalink / raw) Really thanks. :-) -- Ciao, Sandro Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Bit manipulation @ 2005-02-07 12:37 Maurizio 2005-02-07 13:20 ` Martin Krischik ` (3 more replies) 0 siblings, 4 replies; 71+ messages in thread From: Maurizio @ 2005-02-07 12:37 UTC (permalink / raw) hi, i need two hint: i need to acces to a 32 bit word (Interfaces.Unsigned_32). how i can do to take the three m.s.bit? (30,31,32) second, i need to send the 32 bit word over a Tcp connection to a C program, but socket work with usigned 8 bit word, so i need to split the 32 bit in 4 8bit word, and when i read from the socket take 4 8bit word and combine in a 32 word. i see that Ada.Unchecked_Conversion work (in an ada client/server test program) but is correct? --com_buffer_type is an array of 128 32bit word subtype Datas is Ada.Streams.Stream_Element_Array(1..512); --128*4 function To_Raw is new Ada.Unchecked_Conversion ( Source => Com_Buffer_Type, --Interfaces.Unsigned_32 Target => Datas); --Stream_Element is mod 2 ** Standard'Storage_Unit function From_Raw is new Ada.Unchecked_Conversion ( Source => Datas, Target => Com_Buffer_Type); ---------------------- best regards Maurizio ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2005-02-07 12:37 Bit manipulation Maurizio @ 2005-02-07 13:20 ` Martin Krischik 2005-02-07 15:32 ` Martin Dowie ` (2 subsequent siblings) 3 siblings, 0 replies; 71+ messages in thread From: Martin Krischik @ 2005-02-07 13:20 UTC (permalink / raw) Maurizio wrote: > hi, i need two hint: > > i need to acces to a 32 bit word (Interfaces.Unsigned_32). > how i can do to take the three m.s.bit? (30,31,32) Have you considered using a packed array? http://en.wikibooks.org/wiki/Programming:Ada:Types:array#with_aliased_elements Prehaps on conjunction with Unchecked_Conversion. > second, i need to send the 32 bit word over a Tcp connection to a C > program, but > socket work with usigned 8 bit word, so i need to split the 32 bit in > 4 8bit word, > and when i read from the socket take 4 8bit word and combine in a 32 > word. > > i see that Ada.Unchecked_Conversion work (in an ada client/server test > program) but is correct? > > --com_buffer_type is an array of 128 32bit word > > subtype Datas is Ada.Streams.Stream_Element_Array(1..512); --128*4 Stream Elements are normaly not used directly. Ada.Streams only provide a framework for the 'Read, 'Write, 'Input, and 'Output attributes. If you know Java: It works a bit like the Serializable interface. 'Read, 'Write are low level - reading and writing raw data. 'Input, and 'Output are high level - storing array bound, object type etc. pp. as well. > function To_Raw is > new Ada.Unchecked_Conversion > ( > Source => Com_Buffer_Type, --Interfaces.Unsigned_32 > Target => Datas); --Stream_Element is mod 2 ** > Standard'Storage_Unit > function From_Raw is > new Ada.Unchecked_Conversion > ( > Source => Datas, > Target => Com_Buffer_Type); You should give com_buffer_type'Write (Stream, Datas) a try. Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2005-02-07 12:37 Bit manipulation Maurizio 2005-02-07 13:20 ` Martin Krischik @ 2005-02-07 15:32 ` Martin Dowie 2005-02-07 18:04 ` Martin Krischik 2005-02-08 0:32 ` Randy Brukardt 2005-02-08 3:11 ` Steve 3 siblings, 1 reply; 71+ messages in thread From: Martin Dowie @ 2005-02-07 15:32 UTC (permalink / raw) Maurizio wrote: > hi, i need two hint: > > i need to acces to a 32 bit word (Interfaces.Unsigned_32). > how i can do to take the three m.s.bit? (30,31,32) As you would in 'C' - mask them, e.g. use type Interfaces.Unsigned_32; function Get_3_msb (I : Interfaces.Unsigned_32) return Interfaces.Unsigned_32 is begin return I and 16#E000_0000#; -- top 3 bits only end Get_3_msb; Cheers -- Martin ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2005-02-07 15:32 ` Martin Dowie @ 2005-02-07 18:04 ` Martin Krischik 0 siblings, 0 replies; 71+ messages in thread From: Martin Krischik @ 2005-02-07 18:04 UTC (permalink / raw) Martin Dowie wrote: > Maurizio wrote: >> hi, i need two hint: >> >> i need to acces to a 32 bit word (Interfaces.Unsigned_32). >> how i can do to take the three m.s.bit? (30,31,32) > > As you would in 'C' - mask them, e.g. > > use type Interfaces.Unsigned_32; > > function Get_3_msb (I : Interfaces.Unsigned_32) > return Interfaces.Unsigned_32 is > begin > return I and 16#E000_0000#; -- top 3 bits only > end Get_3_msb; From the question it sounds like he need the bits as three Booleans. Of corse a simple compare with 0 will help here. Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2005-02-07 12:37 Bit manipulation Maurizio 2005-02-07 13:20 ` Martin Krischik 2005-02-07 15:32 ` Martin Dowie @ 2005-02-08 0:32 ` Randy Brukardt 2005-02-08 3:11 ` Steve 3 siblings, 0 replies; 71+ messages in thread From: Randy Brukardt @ 2005-02-08 0:32 UTC (permalink / raw) "Maurizio" <maurizio.ferracini@gmail.com> wrote in message news:211db0ae.0502070437.54add641@posting.google.com... > hi, i need two hint: > > i need to acces to a 32 bit word (Interfaces.Unsigned_32). > how i can do to take the three m.s.bit? (30,31,32) > > second, i need to send the 32 bit word over a Tcp connection to a C > program, but > socket work with usigned 8 bit word, so i need to split the 32 bit in > 4 8bit word, > and when i read from the socket take 4 8bit word and combine in a 32 > word. > > i see that Ada.Unchecked_Conversion work (in an ada client/server test > program) but is correct? In both cases, I'd define an appropriate record type and use Unchecked_Conversion to convert it to a 32-bit word. I'll leave the details for someone else to explain. Randy. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2005-02-07 12:37 Bit manipulation Maurizio ` (2 preceding siblings ...) 2005-02-08 0:32 ` Randy Brukardt @ 2005-02-08 3:11 ` Steve 2005-02-08 18:51 ` tmoran 3 siblings, 1 reply; 71+ messages in thread From: Steve @ 2005-02-08 3:11 UTC (permalink / raw) "Maurizio" <maurizio.ferracini@gmail.com> wrote in message news:211db0ae.0502070437.54add641@posting.google.com... > hi, i need two hint: > > i need to acces to a 32 bit word (Interfaces.Unsigned_32). > how i can do to take the three m.s.bit? (30,31,32) > What do you mean by "take the three m.s.bit?" My guess is you either want to determine the value of the individual bits or you want to mask out the other bits. The following example should do either: input_value : Interfaces.Unsigned_32; masked_value : Interfaces.Unsigned_32; bit30 : Boolean; bit31 : Boolean; bit32 : Boolean; begin input_value := Get_Value( ... ); -- some function returning the value you want to mask masked_value = input_value and 16#E000_0000#; bit30 := (input_value and 16#2000_0000#) /= 0; bit31 := (input_value and 16#4000_0000#) /= 0; bit32 := (input_value and 16#8000_0000#) /= 0; Note: You could give the values in binary: 2#0010_0000_0000_0000_0000_0000_0000_0000# is the same as: 16#20000000# > second, i need to send the 32 bit word over a Tcp connection to a C > program, but > socket work with usigned 8 bit word, so i need to split the 32 bit in > 4 8bit word, > and when i read from the socket take 4 8bit word and combine in a 32 > word. You should look beware of "network byte order" when you do this mapping. The built in functions "htonl" and "ntohl" swizzle the bytes into network byte order (if they are available). Network byte order is basically big endian. I have seen a lot of code that ignores the standards for byte ordering, but the socket API's I have seen obey. Here's a snippet of code I use to swizzle the 32 bit floating point value into a 32 bit unsigned long value: TYPE aByte IS MOD 256; FOR aByte'SIZE USE 8; TYPE aByteArray IS ARRAY( Positive RANGE <> ) OF aByte'SIZE ; PRAGMA PACK( aByteArray ); FUNCTION hftonl( value : s_float ) RETURN u_long IS TYPE aFourBytes IS NEW aByteArray(1..4); FUNCTION Conv IS NEW Unchecked_Conversion( aFourBytes, u_long ); FUNCTION Conv IS NEW Unchecked_Conversion( s_float, aFourBytes ); temp : aFourBytes := Conv( value ); BEGIN RETURN Conv( aFourBytes'( temp(4), temp(3), temp(2), temp(1) ) ); END hftonl; I hope this helps, Steve (The Duck) > i see that Ada.Unchecked_Conversion work (in an ada client/server test > program) but is correct? > > --com_buffer_type is an array of 128 32bit word > > subtype Datas is Ada.Streams.Stream_Element_Array(1..512); --128*4 > > function To_Raw is > new Ada.Unchecked_Conversion > ( > Source => Com_Buffer_Type, --Interfaces.Unsigned_32 > Target => Datas); --Stream_Element is mod 2 ** > Standard'Storage_Unit > > function From_Raw is > new Ada.Unchecked_Conversion > ( > Source => Datas, > Target => Com_Buffer_Type); > > ---------------------- > best regards > Maurizio ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Bit manipulation 2005-02-08 3:11 ` Steve @ 2005-02-08 18:51 ` tmoran 0 siblings, 0 replies; 71+ messages in thread From: tmoran @ 2005-02-08 18:51 UTC (permalink / raw) > > second, i need to send the 32 bit word over a Tcp connection to a C > > program, but > > socket work with usigned 8 bit word, so i need to split the 32 bit in > > 4 8bit word, > > and when i read from the socket take 4 8bit word and combine in a 32 > > word. > > You should look beware of "network byte order" when you do this mapping. He did not say he was communicating with some other program that expected a certain byte order, so he's free to choose any order he wants. Of course the C program might be on another machine with another byte order, or another floating point representation, etc, so he might need to convert a 32 bit "word" on machine A to the equivalent on machine B. ^ permalink raw reply [flat|nested] 71+ messages in thread
* bit manipulation @ 1999-04-04 0:00 Jack Chow 1999-04-04 0:00 ` Matthew Heaney 1999-04-05 0:00 ` dennison 0 siblings, 2 replies; 71+ messages in thread From: Jack Chow @ 1999-04-04 0:00 UTC (permalink / raw) Can anyone tell me how to do bit manipulation such as bitwise-and and bitwise or? I am a C programmer. Thanks in advance. Jack Chow ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: bit manipulation 1999-04-04 0:00 bit manipulation Jack Chow @ 1999-04-04 0:00 ` Matthew Heaney 1999-04-05 0:00 ` dennison 1 sibling, 0 replies; 71+ messages in thread From: Matthew Heaney @ 1999-04-04 0:00 UTC (permalink / raw) Jack Chow <jackchow@home.com> writes: > Can anyone tell me how to do bit manipulation such as bitwise-and and > bitwise or? For modular types, of the form type T is mod 256; -- or whatever modulus is req'd then bitwise "and" and "or" are provided as primitive operations: O1, O2 : T; begin O3 := O1 and O2; O4 := O2 or O3; You can also do and'ing and or'ing of boolean arrays: type Bit_Array is array (Positive range 0 .. 7) of Boolean; for Bit_Array'Size use 8; pragma Pack (Bit_Array); O1, O2 : Bit_Array; begin O3 := O1 and O2; O4 := O2 or O3; Realize that there's often a higher-level way to accomplish a goal in Ada than in C. For example, you can declare a record and specify the location of the components: type RT is record A : Integer range 0 .. 3; B : Integer range 0 .. 15; C : Integer range 0 .. 3; end record; for RT use record A at 0 range 0 .. 1; B at 0 range 2 .. 5; C at 0 range 6 .. 7; end record; for RT'Size use 8; O : RT; begin O.A := 1; O.B := 2; O.C := 0; No bit-level manipulation of the fields is required. You can also use the bit-manipulation facilities in the package Interfaces, described in Annex B of your RM. There's an online RM at the Ada home. <http://www.adahome.com/> ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: bit manipulation 1999-04-04 0:00 bit manipulation Jack Chow 1999-04-04 0:00 ` Matthew Heaney @ 1999-04-05 0:00 ` dennison 1 sibling, 0 replies; 71+ messages in thread From: dennison @ 1999-04-05 0:00 UTC (permalink / raw) In article <37072A45.2B3BCE90@home.com>, jcchow@interchange.ubc.ca wrote: > Can anyone tell me how to do bit manipulation such as bitwise-and and > bitwise or? > > I am a C programmer. > > Thanks in advance. > > Jack Chow (Assuming you are using the most recent version of Ada) There are several ways of doing this. Which one is right for you depends on what you want to do with the object. If you also want to be able to manipulate the same objects as integers ( +, -, /, *, etc), then Ada's modular integer types were designed for this purpose. If all you ever want to look at individual bits and perform bitwise operations, then you can use a packed array of booleans indexed by an enumeration: type Status_Bit_Indices is (Success, Parity, ...); type Status_Bit_Array is array (Status_Bit_Indices) of Boolean; pragma Pack Status_Bit_Array; for Status_Bit_Array'size use 32; The boolean operations "and", "or", "not" etc. are predefined to work in a bitwise manner on such arrays. T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2005-02-08 18:51 UTC | newest] Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-07 0:00 Bit manipulation Sandro Binetti 2000-11-07 0:00 ` gdemont 2000-11-08 7:22 ` Sandro Binetti 2000-11-07 0:00 ` Larry Kilgallen 2000-11-07 0:00 ` John English 2000-11-08 0:00 ` gdemont 2000-11-08 0:00 ` Robert Dewar 2000-11-08 0:00 ` Sandro Binetti 2000-11-08 0:00 ` Nicolas Brunot 2000-11-08 0:00 ` gdemont 2000-11-09 4:00 ` Ken Garlington 2000-11-09 0:00 ` Larry Kilgallen 2000-11-09 0:00 ` Ken Garlington 2000-11-08 0:00 ` Dale Stanbrough 2000-11-09 0:00 ` Sandro Binetti 2000-11-09 0:00 ` Ken Garlington 2000-11-09 0:00 ` gdemont 2000-11-10 0:00 ` Scott Ingram 2000-11-09 3:59 ` Ken Garlington 2000-11-09 4:52 ` Robert Dewar 2000-11-08 0:00 ` gdemont 2000-11-08 0:00 ` Larry Kilgallen 2000-11-09 4:50 ` Robert Dewar 2000-11-10 0:00 ` Lao Xiao Hai 2000-11-09 4:47 ` Robert Dewar 2000-11-09 0:00 ` gdemont 2000-11-11 0:00 ` Redryder 2000-11-11 0:00 ` Jeff Carter 2000-11-11 0:00 ` Redryder 2000-11-12 2:07 ` Ken Garlington 2000-11-12 5:56 ` Jeff Carter 2000-11-12 0:00 ` Robert Dewar 2000-11-12 0:00 ` tmoran 2000-11-13 0:00 ` Robert Dewar 2000-11-14 0:00 ` Marc A. Criley 2000-11-13 0:54 ` Ken Garlington 2000-11-12 6:40 ` tmoran 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Pat Rogers 2000-11-13 0:00 ` Brian Rogoff 2000-11-13 0:00 ` F. Britt Snodgrass 2000-11-15 0:00 ` Lutz Donnerhacke 2000-11-13 0:00 ` Pat Rogers 2000-11-14 0:00 ` Georg Bauhaus 2000-11-15 0:00 ` Lutz Donnerhacke 2000-11-14 0:00 ` Martin Dowie 2000-11-15 0:00 ` Lutz Donnerhacke 2000-11-20 0:00 ` Randy Brukardt 2000-11-21 0:00 ` Lutz Donnerhacke 2000-11-21 0:00 ` Stephen Leake 2000-11-22 0:00 ` Lutz Donnerhacke 2000-11-08 7:18 ` Sandro Binetti 2000-11-10 7:24 ` Thank you all for your contribution ! Sandro Binetti -- strict thread matches above, loose matches on Subject: below -- 2005-02-07 12:37 Bit manipulation Maurizio 2005-02-07 13:20 ` Martin Krischik 2005-02-07 15:32 ` Martin Dowie 2005-02-07 18:04 ` Martin Krischik 2005-02-08 0:32 ` Randy Brukardt 2005-02-08 3:11 ` Steve 2005-02-08 18:51 ` tmoran 1999-04-04 0:00 bit manipulation Jack Chow 1999-04-04 0:00 ` Matthew Heaney 1999-04-05 0:00 ` dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox