* RISC @ 2001-03-14 20:23 chris.danx 2001-03-14 21:57 ` RISC Tucker Taft ` (4 more replies) 0 siblings, 5 replies; 82+ messages in thread From: chris.danx @ 2001-03-14 20:23 UTC (permalink / raw) Hi, I'm simulating a RISC machine in Ada. Eventually the instructions will be mapped to native architecture (x86, m68xxx, SPARC, etc), but for now i want to simulate a machine, to limit the possibility of doing something nasty to anyone's machine. I've decided to provide byte, word and long word modes for most instructions. The problem comes when clearing or setting byte or word portions of a register (the machine is loosely based on M68000). The register is long word (32bit) and i want to set the lower 16bits or 8bits. I've managed to get this to work, problem is it's not very efficient. The register is of type 'mod', so i divided by 2**8 or 2**16 then multiplied by it. I know multiplication and division are costly and really i'm looking for something more efficient. If this were Pascal i'd use 'shift left/right' which is quite fast. What should i do to speed it up? Does Ada have a shift L/R operation? Is there another way to do it? I have another problem with memory. I thought about allocating one big block of memory (as an array) and accessing it by index. The problem? I do plan to dynamically allocate the memory, but i'll still be limited by the amount of memory allocable in a single array. I've thought of a few ways of doing this but can't seem to avoid problems! Anyone know of a solution? I don't like using C, but i 'd run in to a similar problem binding with C anyway. Thanks, Chris Campbell p.s. This isn't a homework assignment!!! ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 20:23 RISC chris.danx @ 2001-03-14 21:57 ` Tucker Taft 2001-03-14 22:36 ` RISC chris.danx 2001-03-15 12:37 ` RISC chris.danx ` (3 subsequent siblings) 4 siblings, 1 reply; 82+ messages in thread From: Tucker Taft @ 2001-03-14 21:57 UTC (permalink / raw) "chris.danx" wrote: > > Hi, > I'm simulating a RISC machine in Ada. Eventually the instructions will > be mapped to native architecture (x86, m68xxx, SPARC, etc), but for now i > want to simulate a machine, to limit the possibility of doing something > nasty to anyone's machine. > > I've decided to provide byte, word and long word modes for most > instructions. The problem comes when clearing or setting byte or word > portions of a register (the machine is loosely based on M68000). The > register is long word (32bit) and i want to set the lower 16bits or 8bits. > I've managed to get this to work, problem is it's not very efficient. > > The register is of type 'mod', so i divided by 2**8 or 2**16 then multiplied > by it. I know multiplication and division are costly and really i'm looking > for something more efficient. If this were Pascal i'd use 'shift > left/right' which is quite fast. What should i do to speed it up? Does Ada > have a shift L/R operation? Is there another way to do it? There are a few: 1) Declare a record type (or types) and use a record rep clause (or clauses) to define the fields you are interested in. 2) Use Interfaces.Unsigned_* and use the shifting operations there 3) Use a packed bit array and use slicing (efficiency will probably vary significantly from compiler to compiler on this one) 4) Use a modular type and use "and" with 255 or 65535 to extract the low-order 8/16 bits. > > I have another problem with memory. I thought about allocating one big > block of memory (as an array) and accessing it by index. The problem? I do > plan to dynamically allocate the memory, but i'll still be limited by the > amount of memory allocable in a single array. I've thought of a few ways of > doing this but can't seem to avoid problems! Anyone know of a solution? I > don't like using C, but i 'd run in to a similar problem binding with C > anyway. One good way to deal with large address spaces is to break the address up into a page index and an offset within page, or even a segment/page/offset. E.g., the segment is the high 12 bits, the page index is the next 8 bits, and the offset within page is the low-order 12 bits. You then have a top-level segment table with 4096 segments, each of which is either null, if nothing has ever been written into that segment, or a pointer to a 256-entry page table. Each entry in the page table is similarly either null, or a pointer to a 4096-byte page, depending on whether anything has ever been written to that page. When reading memory, if the corresponding segment or page entry is null, just return a 0. When writing memory, if the corresponding segment or page entry is null, and the value being written is other than 0, allocate the page, and page table if necessary, and update the segment/page entries to point to these new memory chunks, and then update the appropriate byte(s) in the page. This is essentially one kind of "sparse" array. It also happens to correspond to a way that virtual memory is implemented by a typical MMU. > Thanks, > Chris Campbell > > p.s. This isn't a homework assignment!!! -- -Tucker Taft stt@avercom.net http://www.averstar.com/~stt/ Chief Technology Officer, AverCom Corporation (A Titan Company) Burlington, MA USA (AverCom was formerly the Commercial Division of AverStar: http://www.averstar.com/services/ebusiness_applications.html) ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 21:57 ` RISC Tucker Taft @ 2001-03-14 22:36 ` chris.danx 2001-03-14 23:03 ` RISC Fraser Wilson 0 siblings, 1 reply; 82+ messages in thread From: chris.danx @ 2001-03-14 22:36 UTC (permalink / raw) Thanks for the info. One thing i don't get is > 4) use a modular type and use "and" with 255 or 65535 to extract the lower-order > 8/16bits. The problem is in clearing/setting the lower 8/16bits, not extracting them. I simply took the 'mod' of the register to 255/65535 to get this. Still this maybe inefficient, i'll try it that way thanks. For 16bit extract 0000FFFF and Register? Is that correct? Still don't know how to clear or set the lower bits while preserving the top 16/24. What did you mean by > 1) Declare a record type (or types) and use a record rep clause (or clauses) > to define the fields you are interested in. I don't know what you mean by this. I put my code for the 'set' word/byte in, maybe it'll explain it better than i can. * -- a type representing the register; * -- * type register * is record * * id : natural; * data : register_block; * * end record; * -- set the contents of a register; * -- * procedure set_data (reg : in out register; * data : in word) is * begin * -- and this! * reg.data := ((reg.data / 65536) * 65536) xor long_word(data); * end set_data; * -- set the contents of a register; * -- * procedure set_data (reg : in out register; * data : in byte) is * begin * -- i've got to improve the efficiency of this; * reg.data := ((reg.data / 256) * 256 ) xor register_block(data); * end set_data; thanks, Christopher Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 22:36 ` RISC chris.danx @ 2001-03-14 23:03 ` Fraser Wilson 2001-03-15 1:30 ` RISC Corey Ashford 2001-03-15 9:19 ` RISC chris.danx 0 siblings, 2 replies; 82+ messages in thread From: Fraser Wilson @ 2001-03-14 23:03 UTC (permalink / raw) "chris.danx" <chris.danx@ntlworld.com> writes: > * procedure set_data (reg : in out register; > * data : in word) is > * begin > * -- and this! > * reg.data := ((reg.data / 65536) * 65536) xor long_word(data); > * end set_data; If that's inefficient, what about reg.data := (reg.data and 16#FFFF0000) or register_block (data); > * -- i've got to improve the efficiency of this; > * reg.data := ((reg.data / 256) * 256 ) xor register_block(data); Similarly, reg.data := (reg.data and 16#FFFFFF00#) or register_block (data); Fraser. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 23:03 ` RISC Fraser Wilson @ 2001-03-15 1:30 ` Corey Ashford 2001-03-15 9:19 ` RISC chris.danx 1 sibling, 0 replies; 82+ messages in thread From: Corey Ashford @ 2001-03-15 1:30 UTC (permalink / raw) "Fraser Wilson" <fraser@whitelion.org> wrote in message news:fy7y9u8hs24.fsf@whitelion.org... > "chris.danx" <chris.danx@ntlworld.com> writes: > > > * procedure set_data (reg : in out register; > > * data : in word) is > > * begin > > * -- and this! > > * reg.data := ((reg.data / 65536) * 65536) xor long_word(data); > > * end set_data; > > > If that's inefficient, what about > As a side note, I would bet that most compilers would optimize the line above to (using C shift terminology): reg.data := ((reg.data >> 16) << 16) xor long_word(data); I know the Apex compiler would. If the divisor and/or multiplier are not numbers or named numbers, then the compiler would not be able to do that optimization, however. Similarly, a mod operation with a number that's a power of two would be optimized to an AND operation with the proper mask. - Corey > reg.data := (reg.data and 16#FFFF0000) or register_block (data); > > > * -- i've got to improve the efficiency of this; > > * reg.data := ((reg.data / 256) * 256 ) xor register_block(data); > > Similarly, > reg.data := (reg.data and 16#FFFFFF00#) or register_block (data); > > Fraser. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 23:03 ` RISC Fraser Wilson 2001-03-15 1:30 ` RISC Corey Ashford @ 2001-03-15 9:19 ` chris.danx 1 sibling, 0 replies; 82+ messages in thread From: chris.danx @ 2001-03-15 9:19 UTC (permalink / raw) Thanks for that, Chris Campbell "Fraser Wilson" <fraser@whitelion.org> wrote in message news:fy7y9u8hs24.fsf@whitelion.org... > "chris.danx" <chris.danx@ntlworld.com> writes: > > > * procedure set_data (reg : in out register; > > * data : in word) is > > * begin > > * -- and this! > > * reg.data := ((reg.data / 65536) * 65536) xor long_word(data); > > * end set_data; > > > If that's inefficient, what about > > reg.data := (reg.data and 16#FFFF0000) or register_block (data); > > > * -- i've got to improve the efficiency of this; > > * reg.data := ((reg.data / 256) * 256 ) xor register_block(data); > > Similarly, > reg.data := (reg.data and 16#FFFFFF00#) or register_block (data); > > Fraser. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 20:23 RISC chris.danx 2001-03-14 21:57 ` RISC Tucker Taft @ 2001-03-15 12:37 ` chris.danx 2001-03-15 13:03 ` RISC Tarjei T. Jensen 2001-03-15 14:40 ` RISC Ted Dennison 2001-03-16 20:08 ` RISC chris.danx ` (2 subsequent siblings) 4 siblings, 2 replies; 82+ messages in thread From: chris.danx @ 2001-03-15 12:37 UTC (permalink / raw) I'm curious about 'mod' types. If i define a type 'byte' like so * type byte is mod 256; will it occupy one byte of memory. similarly if i define * type word is mod 65536 will it occupy two bytes. This is important for IO and for memory in the simulation. Is it compiler dependant? I'm using GNAT 3.13p just in case this is so. As i was writing i suddenly realised i got a problem with little/big endian-ness. I'm writing files on an Athlon(so it's x86) which is little(i think). If i port to a M68000 say, which is big endian (again i'm unsure), what should i do to convert the 'bytecode' file. I dunno what to do with this. I do plan to port to other platforms in the future so this is important. Is it true that all networks use big endian? Anyway this is for the future, just thought i'd ask in case i need to plan ahead for this. Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 12:37 ` RISC chris.danx @ 2001-03-15 13:03 ` Tarjei T. Jensen 2001-03-15 18:29 ` RISC Robert A Duff 2001-03-15 14:40 ` RISC Ted Dennison 1 sibling, 1 reply; 82+ messages in thread From: Tarjei T. Jensen @ 2001-03-15 13:03 UTC (permalink / raw) chris.danx wrote in message ... >I'm curious about 'mod' types. If i define a type 'byte' like so > >* type byte is mod 256; > >will it occupy one byte of memory. > > >similarly if i define > >* type word is mod 65536 > >will it occupy two bytes. You need to add for byte'size use 8; for word'size use 16; if you use arrays or records it can be a good idea to use pragma(pack); >As i was writing i suddenly realised i got a problem with little/big >endian-ness. I'm writing files on an Athlon(so it's x86) which is little(i >think). If i port to a M68000 say, which is big endian (again i'm unsure), >what should i do to convert the 'bytecode' file. I dunno what to do with >this. I do plan to port to other platforms in the future so this is >important. Is it true that all networks use big endian? Anyway this is for >the future, just thought i'd ask in case i need to plan ahead for this. The IP protocol tends to be big endian. However don't let that keep you from creating a little endian risc machine. You can probably select endianness with the bit_order attribute. You can choose between 'bit_order=low_order_first or high_order_first. Or you can read and write the program one byte at a time. Greetings, ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 13:03 ` RISC Tarjei T. Jensen @ 2001-03-15 18:29 ` Robert A Duff 0 siblings, 0 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-15 18:29 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > You need to add > for byte'size use 8; > for word'size use 16; > if you use arrays or records it can be a good idea to use pragma(pack); I would suggest "for Array_Type'Component_Size use 8;" instead of pragma Pack, if you care about the exact size of array elements. (It's true that pragma Pack will do essentially the same thing in this case.) - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 12:37 ` RISC chris.danx 2001-03-15 13:03 ` RISC Tarjei T. Jensen @ 2001-03-15 14:40 ` Ted Dennison 2001-03-15 14:49 ` RISC Robert A Duff 1 sibling, 1 reply; 82+ messages in thread From: Ted Dennison @ 2001-03-15 14:40 UTC (permalink / raw) In article <NH2s6.4048$y47.865896@news2-win.server.ntlworld.com>, chris.danx says... > >I'm curious about 'mod' types. If i define a type 'byte' like so > >* type byte is mod 256; > >will it occupy one byte of memory. It will if you also do the following: for byte'size use 8; If you don't do that, its completely up to the compiler. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 14:40 ` RISC Ted Dennison @ 2001-03-15 14:49 ` Robert A Duff 2001-03-15 17:37 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Robert A Duff @ 2001-03-15 14:49 UTC (permalink / raw) Ted Dennison<dennison@telepath.com> writes: > In article <NH2s6.4048$y47.865896@news2-win.server.ntlworld.com>, chris.danx > says... > > > >I'm curious about 'mod' types. If i define a type 'byte' like so > > > >* type byte is mod 256; > > > >will it occupy one byte of memory. > > It will if you also do the following: > > for byte'size use 8; > > If you don't do that, its completely up to the compiler. That's not quite right. 'Size clauses on *subtypes* don't necessarily do what you most people think (unfortunately). Byte'Size = 8 by default, and whether you say the above or not, it's a *minimum* size -- the compiler is free to allocate 32 bits for an object of type Byte. In fact, for a parameter, the object will most likely end up in a register. If you want to control the size of an object, put a 'Size clause on the object. Or if it's a record or array component, use a record_rep_clause or a Component_Size clause (resp). - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 14:49 ` RISC Robert A Duff @ 2001-03-15 17:37 ` Marin David Condic 2001-03-15 18:28 ` RISC Robert A Duff 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-15 17:37 UTC (permalink / raw) To make matters worse, a compiler is free in general to refuse to accept *any* representation clause - You Can't Always Get What You Want.... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccpufjaxz5.fsf@world.std.com... > That's not quite right. 'Size clauses on *subtypes* don't necessarily > do what you most people think (unfortunately). > > Byte'Size = 8 by default, and whether you say the above or not, it's a > *minimum* size -- the compiler is free to allocate 32 bits for an object > of type Byte. In fact, for a parameter, the object will most likely end > up in a register. > > If you want to control the size of an object, put a 'Size clause on the > object. Or if it's a record or array component, use a record_rep_clause > or a Component_Size clause (resp). ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 17:37 ` RISC Marin David Condic @ 2001-03-15 18:28 ` Robert A Duff 2001-03-15 19:16 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Robert A Duff @ 2001-03-15 18:28 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > To make matters worse, a compiler is free in general to refuse to accept > *any* representation clause - You Can't Always Get What You Want.... True, but don't all compilers these days support the SP annex, which requires a fair amount of support for rep clauses? Anyway, in practise, "for Byte_Object'Size use 8;" will probably be accepted by every compiler for every 8-bit-byte-addressable machine, and will work as you expect. It's just the 'Size on subtypes that has "questionable" semantics. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 18:28 ` RISC Robert A Duff @ 2001-03-15 19:16 ` Marin David Condic 2001-03-16 8:44 ` RISC Martin Dowie 2001-03-16 15:09 ` RISC Tucker Taft 0 siblings, 2 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-15 19:16 UTC (permalink / raw) Oh sure. Most garden variety representation clauses get listened to and obeyed. At least in my experience. I just like to complain about the inability to coerce behavior out of compilers sometimes. I know I've come up with perfectly reasonable and legal representation specifications from time to time and had them rejected by compilers because a) they didn't understand what I wanted or b) they *did* understand and refused to do it because obviously they knew better than I did what it is I *really* wanted, if only I was as smart and omnipotent as the compiler. That's when you have to get creative in the stories you tell to the compiler! :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccbsr23n0q.fsf@world.std.com... > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > > > To make matters worse, a compiler is free in general to refuse to accept > > *any* representation clause - You Can't Always Get What You Want.... > > True, but don't all compilers these days support the SP annex, which > requires a fair amount of support for rep clauses? Anyway, in practise, > "for Byte_Object'Size use 8;" will probably be accepted by every > compiler for every 8-bit-byte-addressable machine, and will work as you > expect. It's just the 'Size on subtypes that has "questionable" > semantics. > > - Bob > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 19:16 ` RISC Marin David Condic @ 2001-03-16 8:44 ` Martin Dowie 2001-03-16 14:40 ` RISC Marin David Condic 2001-03-16 15:09 ` RISC Tucker Taft 1 sibling, 1 reply; 82+ messages in thread From: Martin Dowie @ 2001-03-16 8:44 UTC (permalink / raw) I gave up on record rep clauses a while back after similar frustrations. Am I alone in this? These days, for interface level stuff I work with byte arrays and do all the conversions explicitly myself (loads of modular arithmatic, which I'd have to admit finding quite fun getting what I want sometimes :-) Has anyone been down this path before and stopped any pitfalls I'm not aware of? Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message news:98r4g1$7r1$1@nh.pace.co.uk... > Oh sure. Most garden variety representation clauses get listened to and > obeyed. At least in my experience. I just like to complain about the > inability to coerce behavior out of compilers sometimes. I know I've come up > with perfectly reasonable and legal representation specifications from time > to time and had them rejected by compilers because a) they didn't understand > what I wanted or b) they *did* understand and refused to do it because > obviously they knew better than I did what it is I *really* wanted, if only > I was as smart and omnipotent as the compiler. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 8:44 ` RISC Martin Dowie @ 2001-03-16 14:40 ` Marin David Condic 2001-03-20 10:17 ` RISC Martin Dowie 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-16 14:40 UTC (permalink / raw) No, you are not alone. There have been a number of times that I and others have raised problems in this forum relating to representation clauses. I have had particular troubles with representation clauses on tagged records and private records. I know others have had similar experiences. Inevitably, there are work-arounds that will let you get the job done, but they are typically inefficient or inelegant or, more commonly, both. Resorting to some version of byte arrays & unchecked conversions or overlays is one way of dealing with it. However (while it is typically reasonably efficient) I find those solutions to be inelegant in that - if for no other reason - the compiler ought to know where record fields lie and ought to be able to keep track of that stuff better than I can - so why shouldn't it get the job of knowing where to divide up the bytes and bits? (I want to fight the problem, not the compiler or the language!) If you hide the movement of bytes-to-fields/fields-to-bytes down at some low level, at least you hide the information from the rest of the system and isolate your problems. It just frustrates me because I can see much nicer, much more elegant ways of doing this sort of thing and it is only slightly out of reach..... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Martin Dowie" <martin.dowie@gecm.com> wrote in message news:3ab1d090$1@pull.gecm.com... > I gave up on record rep clauses a while back after similar frustrations. Am > I > alone in this? These days, for interface level stuff I work with byte arrays > and > do all the conversions explicitly myself (loads of modular arithmatic, which > I'd > have to admit finding quite fun getting what I want sometimes :-) > > Has anyone been down this path before and stopped any pitfalls I'm not > aware of? > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 14:40 ` RISC Marin David Condic @ 2001-03-20 10:17 ` Martin Dowie 2001-03-20 14:34 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Martin Dowie @ 2001-03-20 10:17 UTC (permalink / raw) I have to confess to using checked conversion - I hadn't concidered overlays. Thinking about it I'm not sure I could as we try and avoid having _any_ representation clauses on any of the type that we use within the application. If I were to use an overlay, is it possible to use a 'Valid check on the resulting object and verify it that way? Am I right in thinking that overlays are now 'guarenteed' to work as we lay-people expect? I know in '83 they were 'a bad thing' although they worked in every case I ever saw them used. Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message news:98t8la$rc$1@nh.pace.co.uk... > No, you are not alone. There have been a number of times that I and others > have raised problems in this forum relating to representation clauses. I > have had particular troubles with representation clauses on tagged records > and private records. I know others have had similar experiences. Inevitably, > there are work-arounds that will let you get the job done, but they are > typically inefficient or inelegant or, more commonly, both. > > Resorting to some version of byte arrays & unchecked conversions or overlays [snip] ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 10:17 ` RISC Martin Dowie @ 2001-03-20 14:34 ` Marin David Condic 2001-03-20 15:45 ` RISC Ted Dennison 2001-03-20 18:09 ` RISC Martin Dowie 0 siblings, 2 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-20 14:34 UTC (permalink / raw) "Martin Dowie" <martin.dowie@baesystems.com> wrote in message news:3ab72c8f$1@pull.gecm.com... > I have to confess to using checked conversion - I hadn't concidered > overlays. > Do you mean unchecked conversion? That works, but it forces you to move the data twice just to satisfy language rules & may be too inefficient for some apps. Its not A Bad Thing in my estimation, but I'd rather not have to. > Thinking about it I'm not sure I could as we try and avoid having _any_ > representation clauses on any of the type that we use within the > application. > Well, that's fine for everything used internal to the system. The moment data enters/leaves the system from/to some other source, you *really* want to guarantee the representation is what is expected. How would you do this without representation clauses? > If I were to use an overlay, is it possible to use a 'Valid check on the > resulting > object and verify it that way? > You'd have to check with a language lawyer. My impression is that this is what the attribute is for. Go ahead and declare a stream of bytes for the I/O part to work. Once you get the data, you reference an overlaid record to pull the data apart. I think the 'Valid attribute should force a check of the data "assigned" to the record. (Probably works with Unchecked_Conversion as well...) Of course, you just do all this stuff backwards to handle output. > Am I right in thinking that overlays are now 'guarenteed' to work as we > lay-people > expect? I know in '83 they were 'a bad thing' although they worked in every > case I ever saw them used. I don't think overlays were ever not "guaranteed to work" in Ada83 - at least no more or less so than in Ada95. (You may have cases where the compiler or linker pukes on you. I've had this happen attempting to overlay things from different contexts.) They were/are considered to be "A Bad Thing" because of the inherent lack of safety involved. (Much like the use of gotos is frowned upon, but they are still supported.) It is recognized that overlays can provide an elegant and effective solution to a number of problems (such as this one!) if they are used carefully and judiciously. The language attempts to discourage their use because programmers will, like most normal people, abuse the privilege if left unrestrained. I think the ARM probably says something about programs relying on overlays being "erroneous" or some other carefully defined term that basically means "it may work but all bets are off from a language lawyer's perspective." This is probably because there is no good universal way of defining behavior across all hardware and compiler implementations. So go ahead and use overlays, but realize you're operating without a net. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 14:34 ` RISC Marin David Condic @ 2001-03-20 15:45 ` Ted Dennison 2001-03-20 16:39 ` RISC Robert A Duff ` (2 more replies) 2001-03-20 18:09 ` RISC Martin Dowie 1 sibling, 3 replies; 82+ messages in thread From: Ted Dennison @ 2001-03-20 15:45 UTC (permalink / raw) In article <997pq4$i35$1@nh.pace.co.uk>, Marin David Condic says... > >"Martin Dowie" <martin.dowie@baesystems.com> wrote in message >news:3ab72c8f$1@pull.gecm.com... >> I have to confess to using checked conversion - I hadn't concidered >> overlays. >> >Do you mean unchecked conversion? That works, but it forces you to move the >data twice just to satisfy language rules & may be too inefficient for some >apps. Its not A Bad Thing in my estimation, but I'd rather not have to. That's why if the object is largish I typically use unchecked_conversion on pointers to the object instead. Depending on the smarts of the compiler, that might not generate any code at all. I don't like "for use at" overlays. For one thing, initializations get (re)done when the overlay happens, which could wipe out important stuff. For another, the aliasing is (generally) given a much wider scope than is achievable with unchecked conversion. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 15:45 ` RISC Ted Dennison @ 2001-03-20 16:39 ` Robert A Duff 2001-03-20 18:10 ` RISC Martin Dowie 2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie 2 siblings, 0 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-20 16:39 UTC (permalink / raw) Ted Dennison<dennison@telepath.com> writes: > I don't like "for use at" overlays. For one thing, initializations get > (re)done when the overlay happens, which could wipe out important > stuff. No, the programmer has the choice as to whether default initializations happen. They happen by default. To turn them off, say "pragma Import(Ada, X);". See AARM-B.1(38-38.a). >... For another, the aliasing is (generally) given a much wider > scope than is achievable with unchecked conversion. I don't see why. You can declare the overlaid thing local to a procedure. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 15:45 ` RISC Ted Dennison 2001-03-20 16:39 ` RISC Robert A Duff @ 2001-03-20 18:10 ` Martin Dowie 2001-03-20 18:56 ` RISC Ted Dennison 2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie 2 siblings, 1 reply; 82+ messages in thread From: Martin Dowie @ 2001-03-20 18:10 UTC (permalink / raw) > That's why if the object is largish I typically use unchecked_conversion on > pointers to the object instead. Depending on the smarts of the compiler, that > might not generate any code at all. Do you then use 'Valid? ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 18:10 ` RISC Martin Dowie @ 2001-03-20 18:56 ` Ted Dennison 0 siblings, 0 replies; 82+ messages in thread From: Ted Dennison @ 2001-03-20 18:56 UTC (permalink / raw) In article <3ab79b12$1@pull.gecm.com>, Martin Dowie says... > >> That's why if the object is largish I typically use unchecked_conversion >on >> pointers to the object instead. Depending on the smarts of the compiler, >that >> might not generate any code at all. > >Do you then use 'Valid? Well..er...I have to admit that the last time I felt the need to use that trick to go from an unstructured type to a structured one (rather than the other way around) I was using Ada83. I think the only time I've used 'Valid was on a Boolean. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC - largish (code listed) 2001-03-20 15:45 ` RISC Ted Dennison 2001-03-20 16:39 ` RISC Robert A Duff 2001-03-20 18:10 ` RISC Martin Dowie @ 2001-03-22 9:16 ` Martin Dowie 2001-03-22 9:34 ` Martin Dowie 2 siblings, 1 reply; 82+ messages in thread From: Martin Dowie @ 2001-03-22 9:16 UTC (permalink / raw) Something like this? Seems _well_ dangerous but also seems to produce very little code... Ted Dennison <dennison@telepath.com> wrote in message news:LWKt6.1865$94.2578@www.newsranger.com... > That's why if the object is largish I typically use unchecked_conversion on > pointers to the object instead. Depending on the smarts of the compiler, that > might not generate any code at all. > > I don't like "for use at" overlays. For one thing, initializations get (re)done > when the overlay happens, which could wipe out important stuff. For another, the > aliasing is (generally) given a much wider scope than is achievable with > unchecked conversion. -- Unchecked_Accessors Spec: with System; generic type Object1 (<>) is limited private; type Object1_Pointer is access all Object1; with function To_Object1_Pointer (Address : System.Address) return Object1_Pointer; with function To_Object1_Address (Obj1_Ptr : Object1_Pointer) return System.Address; type Object2 (<>) is limited private; type Object2_Pointer is access all Object2; with function To_Object2_Pointer (Address : System.Address) return Object2_Pointer; with function To_Object2_Address (Obj2_Ptr : Object2_Pointer) return System.Address; package Unchecked_Accessors is function To_Object1_Pointer (Obj2_Ptr : Object2_Pointer) return Object1_Pointer; function To_Object2_Pointer (Obj1_Ptr : Object1_Pointer) return Object2_Pointer; pragma Inline (To_Object1_Pointer); pragma Inline (To_Object2_Pointer); end Unchecked_Accessors; -- Unchecked_Accessors Body: package body Unchecked_Accessors is function To_Object1_Pointer (Obj2_Ptr : Object2_Pointer) return Object1_Pointer is begin return To_Object1_Pointer (Address => To_Object2_Address (Obj2_Ptr => Obj2_Ptr)); end To_Object1_Pointer; function To_Object2_Pointer (Obj1_Ptr : Object1_Pointer) return Object2_Pointer is begin return To_Object2_Pointer (Address => To_Object1_Address (Obj1_Ptr => Obj1_Ptr)); end To_Object2_Pointer; end Unchecked_Accessors; -- Test Harness: with Ada.Text_IO; use Ada.Text_IO; with System.Address_To_Access_Conversions; with Unchecked_Accessors; procedure Test_Unchecked_Access_Conversion is type A_Record (Variant : Boolean := False) is record Item1 : Integer; case Variant is when False => Item2 : Float; when True => Item3 : Boolean; Item4 : String (1 .. 10); end case; end record; package Record_Conversions is new System.Address_To_Access_Conversions (Object => A_Record); My_Object : aliased A_Record := (Variant => True, Item1 => Integer'Last, Item3 => True, Item4 => "0123456789"); type A_String is new String (1 .. My_Object'Size / 8); package String_Conversions is new System.Address_To_Access_Conversions (Object => A_String); package My_Conversions is new Unchecked_Accessors (Object1 => A_Record, Object1_Pointer => Record_Conversions.Object_Pointer, To_Object1_Pointer => Record_Conversions.To_Pointer, To_Object1_Address => Record_Conversions.To_Address, Object2 => A_String, Object2_Pointer => String_Conversions.Object_Pointer, To_Object2_Pointer => String_Conversions.To_Pointer, To_Object2_Address => String_Conversions.To_Address); My_String_Access : String_Conversions.Object_Pointer; begin My_String_Access := My_Conversions.To_Object2_Pointer (Obj1_Ptr => My_Object'Access); Put_Line (String (My_String_Access.all)); end Test_Unchecked_Access_Conversion; Assempler for Unchecked_Accessors: .file "unchecked_accessors.adb" gcc2_compiled.: ___gnu_compiled_ada: .stabs "W:/Personal/Ada/Utilities/",100,0,0,Ltext0 .stabs "w:/personal/ada/utilit~1/unchecked_accessors.adb",100,0,0,Ltext0 .text Ltext0: .stabs "long int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0 .stabs "unsigned char:t(0,2)=@s8;r(0,2);0;255;",128,0,0,0 .stabs "boolean___XDLU_0__1:t(0,3)=@s8;efalse:0,true:1,;",128,0,1,0 .stabs "character:t(0,4)=@s8;r(0,4);0;255;",128,0,1,0 .stabs "natural___XDLU_0__2147483647:t(0,5)=r(0,1);0;2147483647;",128,0,1,0 .stabs "access_character:t(0,6)=*(0,4)",128,0,1,0 .stabs "integer:t(0,7)=r(0,1);-2147483648;2147483647;",128,0,1,0 .stabs "exception:T(0,8)=s20not_handled_by_others:(0,3),0,8;c1:(0,4),8,8;c2:(0,4),1 6,8;c3:(0,4),24,8;name_length:(0,5),32,32;full_name:(0,6),64,32;htable_ptr:( 0,6),96,32;import_code:(0,7),128,32;;",128,0,0,0 .stabs "exception:t(0,8)",128,0,1,0 .stabs "long_long_float:t(0,9)=r(0,1);12;0;",128,0,1,0 .globl _unchecked_accessors_E .data .stabs "unchecked_accessors_E:G(0,3)",32,0,13,0 _unchecked_accessors_E: .byte 0 .text .align 4 .stabs "unchecked_accessors___elabb:F(0,10)=(0,10)",36,0,1,_unchecked_accessors___e labb .globl _unchecked_accessors___elabb _unchecked_accessors___elabb: .stabn 68,0,1,LM1-_unchecked_accessors___elabb LM1: pushl %ebp movl %esp,%ebp .stabn 68,0,1,LM2-_unchecked_accessors___elabb LM2: movb $1,_unchecked_accessors_E .stabn 68,0,1,LM3-_unchecked_accessors___elabb LM3: L1: movl %ebp,%esp popl %ebp ret Lscope0: .stabs "",36,0,0,Lscope0-_unchecked_accessors___elabb .text .stabs "",100,0,0,Letext Letext: Test Results: ? ??0123456789 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC - largish (code listed) 2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie @ 2001-03-22 9:34 ` Martin Dowie 0 siblings, 0 replies; 82+ messages in thread From: Martin Dowie @ 2001-03-22 9:34 UTC (permalink / raw) oops forgot the assembler for the instantiation.. still not a lot extra for these 2 routines. Martin Dowie <martin.dowie@baesystems.com> wrote in message news:3ab9c0e9$1@pull.gecm.com... > Something like this? Seems _well_ dangerous but also seems to produce very > little code... > > Ted Dennison <dennison@telepath.com> wrote in message > news:LWKt6.1865$94.2578@www.newsranger.com... > > That's why if the object is largish I typically use unchecked_conversion > on > > pointers to the object instead. Depending on the smarts of the compiler, > that > > might not generate any code at all. > > > > I don't like "for use at" overlays. For one thing, initializations get > (re)done > > when the overlay happens, which could wipe out important stuff. For > another, the > > aliasing is (generally) given a much wider scope than is achievable with > > unchecked conversion. Ltext2: .stabn 68,0,3,LM19-_test_unchecked_access_conversion__my_conversions__to_object1_po inter$2.8 LM19: pushl %ebp movl %esp,%ebp subl $4,%esp movl %ecx,-4(%ebp) .stabn 68,0,5,LM20-_test_unchecked_access_conversion__my_conversions__to_object1_po inter$2.8 LM20: movl 8(%ebp),%eax pushl %eax movl -4(%ebp),%ecx call _test_unchecked_access_conversion__string_conversions__to_address.7 addl $4,%esp movl %eax,%eax pushl %eax movl -4(%ebp),%ecx call _test_unchecked_access_conversion__record_conversions__to_pointer.4 addl $4,%esp movl %eax,%edx movl %edx,%eax jmp L10 .align 2,0x90 .stabn 68,0,5,LM21-_test_unchecked_access_conversion__my_conversions__to_object1_po inter$2.8 LM21: L10: movl %ebp,%esp popl %ebp ret Lscope4: .stabs "",36,0,0,Lscope4-_test_unchecked_access_conversion__my_conversions__to_obje ct1_pointer$2.8 .align 4 .stabs "test_unchecked_access_conversion__my_conversions__to_object2_pointer$2:f(0, 46),test_unchecked_access_conversion__my_conversions__to_object2_pointer$2,t est_unchecked_access_conversion",36,0,8,_test_unchecked_access_conversion__m y_conversions__to_object2_pointer$2.9 .stabs "obj1_ptr:p(0,29)",160,0,15,8 _test_unchecked_access_conversion__my_conversions__to_object2_pointer$2.9: .stabn 68,0,8,LM22-_test_unchecked_access_conversion__my_conversions__to_object2_po inter$2.9 LM22: pushl %ebp movl %esp,%ebp subl $4,%esp movl %ecx,-4(%ebp) .stabn 68,0,10,LM23-_test_unchecked_access_conversion__my_conversions__to_object2_p ointer$2.9 LM23: movl 8(%ebp),%eax pushl %eax movl -4(%ebp),%ecx call _test_unchecked_access_conversion__record_conversions__to_address.5 addl $4,%esp movl %eax,%eax pushl %eax movl -4(%ebp),%ecx call _test_unchecked_access_conversion__string_conversions__to_pointer.6 addl $4,%esp movl %eax,%edx movl %edx,%eax jmp L11 .align 2,0x90 .stabn 68,0,10,LM24-_test_unchecked_access_conversion__my_conversions__to_object2_p ointer$2.9 LM24: L11: movl %ebp,%esp popl %ebp ret ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 14:34 ` RISC Marin David Condic 2001-03-20 15:45 ` RISC Ted Dennison @ 2001-03-20 18:09 ` Martin Dowie 2001-03-20 20:00 ` RISC Marin David Condic 1 sibling, 1 reply; 82+ messages in thread From: Martin Dowie @ 2001-03-20 18:09 UTC (permalink / raw) > Do you mean unchecked conversion? That works, but it forces you to move the > data twice just to satisfy language rules & may be too inefficient for some > apps. Its not A Bad Thing in my estimation, but I'd rather not have to. No, I really meant checked conversions. We have a whole suite of generics that take in enumerations and constant arrays of integers (different subprograms for different sizes) and provide x<->y conversions. For arrays of packed booleans we have subprograms that take in 8/16/32 booleans and do the modulo arithmatic. Not exactly efficient, but they seem to be highly portable. We also provide a endian_convert a parameter (defaulted to false). Most of our data does fall on natural word boundaries anyway (just not all of them) so the really inefficient routines are hardly ever used. In most systems the i/o is a fairly trivial percentage of the %cpu-time and if we need to make any optimisations then there is usually a better candidate after a bit of analysis. > Well, that's fine for everything used internal to the system. The moment > data enters/leaves the system from/to some other source, you *really* want > to guarantee the representation is what is expected. How would you do this > without representation clauses? As above :-) > You'd have to check with a language lawyer. My impression is that this is > what the attribute is for. Go ahead and declare a stream of bytes for the > I/O part to work. Once you get the data, you reference an overlaid record to > pull the data apart. I think the 'Valid attribute should force a check of > the data "assigned" to the record. (Probably works with Unchecked_Conversion > as well...) Of course, you just do all this stuff backwards to handle > output. Any lawyers out there? > I don't think overlays were ever not "guaranteed to work" in Ada83 - at > least no more or less so than in Ada95. (You may have cases where the > compiler or linker pukes on you. I've had this happen attempting to overlay > things from different contexts.) They were/are considered to be "A Bad > Thing" because of the inherent lack of safety involved. (Much like the use > of gotos is frowned upon, but they are still supported.) It is recognized > that overlays can provide an elegant and effective solution to a number of > problems (such as this one!) if they are used carefully and judiciously. The > language attempts to discourage their use because programmers will, like > most normal people, abuse the privilege if left unrestrained. RM83, 13.5.something "Address clauses should not be used to achieve overlays of objects or overlays of program units. Nor should a given interrupt be linked to more than one entry. Any program using address clauses to achieve such effects is erroneous." But I've yet to find anything as explicit about this in RM95 :-( > I think the ARM probably says something about programs relying on overlays > being "erroneous" or some other carefully defined term that basically means > "it may work but all bets are off from a language lawyer's perspective." > This is probably because there is no good universal way of defining behavior > across all hardware and compiler implementations. > > So go ahead and use overlays, but realize you're operating without a net. I may start toying with overlays if this 'Valid thang works... cheers. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 18:09 ` RISC Martin Dowie @ 2001-03-20 20:00 ` Marin David Condic 2001-03-20 22:30 ` RISC Robert A Duff 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-20 20:00 UTC (permalink / raw) Sounds to me like it says: "If you use an address clause to achieve an overlay you are being a very bad, bad, programmer and should be made to stay after programming school and write on the blackboard 'Thou Shalt Not Overlay' 1000 times and learn that the compiler cannot save you if you do stupid things like this. But if nobody is looking and the compiler doesn't complain and it works anyway, the LRM won't have anything against this..." I suppose it depends on your perspective about "rules". Is the Ada83 LRM of the belief that anything not forbidden is mandatory? Or is the Ada83 LRM of the belief that it is easier to get forgiveness than permission? I'd prefer to view the paragraph you cite as the LRM choosing to protect itself by declaring such use erroneous, but not stopping any compiler from giving you exactly what you asked for. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Martin Dowie" <martin.dowie@baesystems.com> wrote in message news:3ab79ade$1@pull.gecm.com... > RM83, 13.5.something > "Address clauses should not be used to achieve overlays of objects or > overlays of program units. Nor should a given interrupt be linked to more > than one entry. Any program using address clauses to achieve such > effects is erroneous." > > But I've yet to find anything as explicit about this in RM95 :-( > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 20:00 ` RISC Marin David Condic @ 2001-03-20 22:30 ` Robert A Duff 2001-03-20 22:48 ` RISC Ted Dennison 2001-03-20 23:10 ` RISC Marin David Condic 0 siblings, 2 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-20 22:30 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Sounds to me like it says: "If you use an address clause to achieve an > overlay you are being a very bad, bad, programmer and should be made to stay > after programming school and write on the blackboard 'Thou Shalt Not > Overlay' 1000 times and learn that the compiler cannot save you if you do > stupid things like this. But if nobody is looking and the compiler doesn't > complain and it works anyway, the LRM won't have anything against this..." Erroneous means that, but it also means that your program can do absolutely anything, including wipe out your disk or (much worse) work properly until you port it or turn on the optimizer or upgrade your compiler. The "erroneous" rule about overlays was removed from Ada 95 quite deliberately, because it was recognized that there are (rare) circumstances where it makes sense to use overlays. And because we weren't entirely sure what "overlay" means in a formal sense. Most of the remaining rules about "erroneous" are there for good reason: eg, an optimizing compiler really might do something very surprising, causing subtle bugs that occur only rarely. And note that rare bugs are the ones that matter. A bug that occurs the first time you run the program will be found right away, and fixed. A rare bug might escape to customers. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 22:30 ` RISC Robert A Duff @ 2001-03-20 22:48 ` Ted Dennison 2001-03-20 23:10 ` RISC Marin David Condic 1 sibling, 0 replies; 82+ messages in thread From: Ted Dennison @ 2001-03-20 22:48 UTC (permalink / raw) In article <wcck85koyz5.fsf@world.std.com>, Robert A Duff says... > >The "erroneous" rule about overlays was removed from Ada 95 quite >deliberately, because it was recognized that there are (rare) >circumstances where it makes sense to use overlays. And because we >weren't entirely sure what "overlay" means in a formal sense. I thought it was just promoted to a "Bounded Error". It can still cease to work if optimization is turned on, can't it? (eg: the compiler decides to keep one alias or part of one alias in a register for a while) Or does the language standard actually require them to work now? --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 22:30 ` RISC Robert A Duff 2001-03-20 22:48 ` RISC Ted Dennison @ 2001-03-20 23:10 ` Marin David Condic 2001-03-21 0:18 ` RISC Robert A Duff 1 sibling, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-20 23:10 UTC (permalink / raw) Sounds reasonable to me. I'd assume that the minute the standard says "erroneous" I could safely expect that the compiler might make monkeys fly from my serial port and this would be "legal" behavior. Hence I'd have to "Boldly Go Where No Man Has Gone Before" and figure out what behavior I get from *my* specific compiler in *my* environment and decide how far to trust it. I don't believe that every program has to be 100% portable, safe or bug-free. If I *know* I'm stepping outside the bounds of normally acceptable programmer conduct and totally beyond the walls of any LRM/ARM protection rules, then from that point on, I'm working closely with my compiler documentation, the vendor, the assembly output, etc., and isolating that to some narrow part of the system. Overlays would fall in that category - they ought to be sufficiently painful to remind you that what you are doing is dangerous, but should remain possible in an implementation dependent manner. (There really aren't many excuses for it - but there are a few...:-) In other words: Never get out of the boat. Not unless you're ready to go all the way. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wcck85koyz5.fsf@world.std.com... > Erroneous means that, but it also means that your program can do > absolutely anything, including wipe out your disk or (much worse) work > properly until you port it or turn on the optimizer or upgrade your > compiler. > > The "erroneous" rule about overlays was removed from Ada 95 quite > deliberately, because it was recognized that there are (rare) > circumstances where it makes sense to use overlays. And because we > weren't entirely sure what "overlay" means in a formal sense. > > Most of the remaining rules about "erroneous" are there for good reason: > eg, an optimizing compiler really might do something very surprising, > causing subtle bugs that occur only rarely. > > And note that rare bugs are the ones that matter. A bug that occurs the > first time you run the program will be found right away, and fixed. A > rare bug might escape to customers. > > - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-20 23:10 ` RISC Marin David Condic @ 2001-03-21 0:18 ` Robert A Duff 2001-03-21 14:31 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Robert A Duff @ 2001-03-21 0:18 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Sounds reasonable to me. I'd assume that the minute the standard says > "erroneous" I could safely expect that the compiler might make monkeys fly > from my serial port and this would be "legal" behavior. Hence I'd have to > "Boldly Go Where No Man Has Gone Before" and figure out what behavior I get > from *my* specific compiler in *my* environment and decide how far to trust > it. And whether that compiler is going to change. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-21 0:18 ` RISC Robert A Duff @ 2001-03-21 14:31 ` Marin David Condic 2001-03-21 16:47 ` RISC Ted Dennison 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-21 14:31 UTC (permalink / raw) Very true. This is why lots of mission critical systems *freeze* a version of the compiler at some juncture in the project. Better the bugs you know than to have something totally unexpected show up in a new release. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccg0g8otyu.fsf@world.std.com... > And whether that compiler is going to change. > > - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-21 14:31 ` RISC Marin David Condic @ 2001-03-21 16:47 ` Ted Dennison 2001-03-21 17:36 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Ted Dennison @ 2001-03-21 16:47 UTC (permalink / raw) In article <99ae0k$g0j$1@nh.pace.co.uk>, Marin David Condic says... > >Very true. This is why lots of mission critical systems *freeze* a version >of the compiler at some juncture in the project. Better the bugs you know >than to have something totally unexpected show up in a new release. But that isn't even sufficient to keep you safe from erronious code. Assuming that the generated code might be affected by how the compiler decides to optimize (a quite reasonable assumption), then your code could cease to work if any of the following happen: o You recompile with a different set of options. o You change a line of code somewhere in the entire system and recompile. and in some cases (notably the old DEC Ada compiler)... o You compile on a different machine. o You compile on the same machine, but with a different amount of free RAM (different set of background processes running at the time). You really should not *ever* use erronious code unless you have some kind of good assurance from your vendor that it will behave predictably (often the vendor docs will mention some such instances). I suppose having access to the sources of your compiler and checking it over yourself might count, but that would probably be more work than finding a better way. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-21 16:47 ` RISC Ted Dennison @ 2001-03-21 17:36 ` Marin David Condic 0 siblings, 0 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-21 17:36 UTC (permalink / raw) Back when I was doing engine controls, we'd get started talking about how the DEC compilers could generate different code depending on available memory & what else was running, etc. Our Configuration Management person would plug her ears and go "I can't hear you YAYAYAYAYAYAYAYA!!!!!!" :-) It was a real worry for Formal CM that we couldn't absolutely GUARANTEE that given the same source code, the same compiler, the same machine and two different days of the week, that we couldn't get the same set of bits out the back end. However, I'd consider your statement about "not *ever*" to be a bit strong. Remember that we were originally talking about doing an overlay by forcing two things to reside at the same spot in memory. If I could get my compiler to do this at all reliably for one structure, it would be a reasonably safe assumption that on two different days of the week, that same structure is going to reside at that same location in memory. (Otherwise, how do I deal with memory mapped devices?) It also seems reasonable that if I got one "for use at" to put something in memory at a specific location and another "for use at" to put a different thing at the same location, and I don't switch compilers, that on a different day of the week, I'll still have those two things residing at the same spot in memory. (This sort of thing is done all the time at low levels of code - getting access to the same physical memory locations from two different perspectives/locations in the code.) Granted, if I pull some sort of trick with access types and start counting on an optimization to fool the compiler into dealing with an overlay, I may have different problems. But I'm talking about a plain vanilla overlay. At some point you have to have *some* level of trust (based on conversations with your vendor, knowledge of the compiler, evidence in the documentation, etc.) that even "erroneous" things will work properly within some known parameters. Otherwise we're down to discussing what might happen to the code if the sun expands to 10 times its current size and the Earth is totally engulfed in fire. (I guess the program crashes and your rocket/payload augers in - tough noogies! :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" <dennison@telepath.com> wrote in message news:lW4u6.325$fy.827@www.newsranger.com... > In article <99ae0k$g0j$1@nh.pace.co.uk>, Marin David Condic says... > > > >Very true. This is why lots of mission critical systems *freeze* a version > >of the compiler at some juncture in the project. Better the bugs you know > >than to have something totally unexpected show up in a new release. > > But that isn't even sufficient to keep you safe from erronious code. Assuming > that the generated code might be affected by how the compiler decides to > optimize (a quite reasonable assumption), then your code could cease to work if > any of the following happen: > > o You recompile with a different set of options. > o You change a line of code somewhere in the entire system and recompile. > > and in some cases (notably the old DEC Ada compiler)... > o You compile on a different machine. > o You compile on the same machine, but with a different amount of free RAM > (different set of background processes running at the time). > > You really should not *ever* use erronious code unless you have some kind of > good assurance from your vendor that it will behave predictably (often the > vendor docs will mention some such instances). I suppose having access to the > sources of your compiler and checking it over yourself might count, but that > would probably be more work than finding a better way. > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-15 19:16 ` RISC Marin David Condic 2001-03-16 8:44 ` RISC Martin Dowie @ 2001-03-16 15:09 ` Tucker Taft 2001-03-16 17:10 ` RISC Robert A Duff 2001-03-16 18:33 ` RISC Marin David Condic 1 sibling, 2 replies; 82+ messages in thread From: Tucker Taft @ 2001-03-16 15:09 UTC (permalink / raw) Marin David Condic wrote: > > Oh sure. Most garden variety representation clauses get listened to and > obeyed. At least in my experience. I just like to complain about the > inability to coerce behavior out of compilers sometimes. I know I've come up > with perfectly reasonable and legal representation specifications from time > to time and had them rejected by compilers because a) they didn't understand > what I wanted or b) they *did* understand and refused to do it because > obviously they knew better than I did what it is I *really* wanted, if only > I was as smart and omnipotent as the compiler. This is my cue to pipe up with the Compiler Writer's Lament. Rep clauses are difficult to support because every special case makes a compiler more complicated and more buggy, and makes optimization harder. So compilers really "want" to do everything one way if possible, and then optimize the heck out of that. With rep-clauses, the programmer is sometimes asking the compiler to violate some of its basic assumptions (e.g., the "tag" is always the first word of the record, the non-variant part precedes the entire variant part, every dynamic-sized component is dumped at the end of the record, with an offset word identifying where it starts, every object is aligned on its "natural" alignment boundary, bit fields never cross word boundaries, packed array components never cross byte boundaries, ...). Of course any one of these assumptions can be examined and declared stupid, and the compiler writer can be scolded for making any such assumptions. On the other hand, the programmer expects that if by chance there is an efficient way of implementing the specified representation, the compiler jolly-well better recognize that fact and do the right thing. E.g., allow me to specify fields that cross word boundaries, but if they don't, then do the efficient in-line field extract. I can assure you that we devote huge quantities of code in our compilers to dealing with programmer-specified representations, and still we find that there are some representations we can't handle. Sometimes we know it, so we reject the rep-clause. Sometimes we don't know it, and generate goofy or incorrect code. So feel a little sympathy for us, and/or get out your check books and pony up some big bucks for the ultimate in rep-clause support ;-). > That's when you have to get creative in the stories you tell to the > compiler! :-) > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > Web: http://www.mcondic.com/ -- -Tucker Taft stt@avercom.net http://www.averstar.com/~stt/ Chief Technology Officer, AverCom Corporation (A Titan Company) Burlington, MA USA (AverCom was formerly the Commercial Division of AverStar: http://www.averstar.com/services/ebusiness_applications.html) ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 15:09 ` RISC Tucker Taft @ 2001-03-16 17:10 ` Robert A Duff 2001-03-16 19:02 ` RISC Marin David Condic ` (2 more replies) 2001-03-16 18:33 ` RISC Marin David Condic 1 sibling, 3 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-16 17:10 UTC (permalink / raw) Tucker Taft <stt@averstar.com> writes: > This is my cue to pipe up with the Compiler Writer's Lament. > Rep clauses are difficult to support because every special case > makes a compiler more complicated and more buggy, and makes > optimization harder. So compilers really "want" to do everything > one way if possible, and then optimize the heck out of that. Ada 83 said that compilers don't have to support rep clauses that can't be "handled simply by the underlying hardware". It's not entirely clear what that means. Ada 95 has a whole lot of verbiage that amounts to more or less the same thing: the compiler has to support some minimal capabilities that we thought were "simple" or "reasonably efficient" on all machines. If I were designing a language from scratch, I think I would require much more, including bit fields oddly aligned, and crossing word boundaries and so forth. I don't think the "underlying hardware" is really the issue, especially in this networked era, the piece of hardware you're trying to mimic might be a different computer, or some weird peripheral device. Tucker's right: these things are hard to implement efficiently. But I think it's worth it. I really think the usefulness of Ada's rep clauses is seriously damaged by their lack of portability. If I ran the circus, all compilers would support exactly the same record layouts. There are also a lot of things that rep clauses just can't express. Eg, TCP/IP protocols often have data structures defined like "a count byte, followed by an array of sub-records" where the count gives the number of sub-records, or the number of bytes including (or not including) the count byte itself. I would like to have a language that could describe that sort of thing at a reasonably high level. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 17:10 ` RISC Robert A Duff @ 2001-03-16 19:02 ` Marin David Condic 2001-03-16 20:58 ` RISC Robert A Duff 2001-03-16 22:19 ` RISC Ted Dennison 2001-03-16 19:13 ` RISC Laurent Guerby 2001-03-16 20:51 ` RISC Ole-Hjalmar Kristensen 2 siblings, 2 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-16 19:02 UTC (permalink / raw) "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccofv1r65n.fsf@world.std.com... > Ada 83 said that compilers don't have to support rep clauses that can't > be "handled simply by the underlying hardware". It's not entirely clear > what that means. > > Ada 95 has a whole lot of verbiage that amounts to more or less the same > thing: the compiler has to support some minimal capabilities that we > thought were "simple" or "reasonably efficient" on all machines. > What it means is that the compiler is free to say "Sexual Penetration Upon You!" whenever it feels like it. :-) An interesting clause I'd like to write into the contracts *I* have to live by! :-) I can live with most of Ada's representation limitations and most of the time don't really care. There just needs to be *some* mechanism for me to say "On the machine I'm targeting, the following layout of bits makes sense - so just do what I tell you to do..." I could deal with restrictions on such represented objects *after* I get the layout I asked for, provided that at minimum, I can assign to/from the object and its sub-fields. (Records or arrays are where I care about this. Most other things just don't matter that much or the compilers that are out there don't seem to puke on the representations as long as they aren't contradictory.). > If I were designing a language from scratch, I think I would require > much more, including bit fields oddly aligned, and crossing word > boundaries and so forth. > Yea Verily And For Sooth! So long as we are going to have to deal with hardware designed by hardware engineers (instead of compiler writers) or communicate with data streams that come from places not programmed in Ada, *someone* is going to create data that needs really bizarre representations. Ada needs to be able to connect to that data - and most of the time it does. > I don't think the "underlying hardware" is really the issue, especially > in this networked era, the piece of hardware you're trying to mimic > might be a different computer, or some weird peripheral device. > From a practical perspective, I don't think it is that much of an issue. In theory, someone might one day (again) make a machine that deals with sixbit data. What is the likelihood there will be a huge demand for Ada compilers for such a machine? Most machines these days are byte oriented. You've got to deal with byte sex, but beyond that you can pretty much count on hardware having some sort of support for byte sized data. It shouldn't be that tough to map most rep clauses onto that sort of machine. > Tucker's right: these things are hard to implement efficiently. But I > think it's worth it. I really think the usefulness of Ada's rep clauses > is seriously damaged by their lack of portability. If I ran the circus, > all compilers would support exactly the same record layouts. > I'll accept the efficiency argument and offer to give up some usages of the data if that helps. Maybe Ada was overly-ambitious in this area and creating some alternative mechanisms that don't have to satisfy all the possible demands might make life easier. > There are also a lot of things that rep clauses just can't express. Eg, > TCP/IP protocols often have data structures defined like "a count byte, > followed by an array of sub-records" where the count gives the number of > sub-records, or the number of bytes including (or not including) the > count byte itself. I would like to have a language that could describe > that sort of thing at a reasonably high level. > Yes - this would be *very* nice! There are often in data streams things of uncertain quantity which become very hard to represent in the usual Ada structures. You get things like "This16 bit word will tell you how many doohickies will follow...." and it will be surrounded by fixed data. It doesn't map well to records - but maybe some other structure could be created to handle it. Typically, you'll end up "rolling-your-own" by building some kind of dynamic data structure to hold these things. You construct the data structure as you read the data in. Not that hard to do, but it would be *really* nice to describe one of these things at a high level and just have all that done for you by the compiler. There would be representation issues here as well, but I think that if the operations on the structure are limited to assignments, it may not be that hard to handle. I'm not at all sure what sort of language features would be needed to support this. I'd be interested in hearing any ideas you had on it. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 19:02 ` RISC Marin David Condic @ 2001-03-16 20:58 ` Robert A Duff 2001-03-19 16:17 ` RISC Marin David Condic 2001-03-16 22:19 ` RISC Ted Dennison 1 sibling, 1 reply; 82+ messages in thread From: Robert A Duff @ 2001-03-16 20:58 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Yea Verily And For Sooth! So long as we are going to have to deal with > hardware designed by hardware engineers (instead of compiler writers) or > communicate with data streams that come from places not programmed in Ada, > *someone* is going to create data that needs really bizarre representations. Bill Wulf wrote something along the lines of: People who design overly complicated hardware should be punished by being forced to write compilers that target to that hardware. > From a practical perspective, I don't think it is that much of an issue. In > theory, someone might one day (again) make a machine that deals with sixbit > data. I'll bet that doesn't happen in my lifetime. ;-) >... What is the likelihood there will be a huge demand for Ada compilers > for such a machine? Most machines these days are byte oriented. You've got > to deal with byte sex, but beyond that you can pretty much count on hardware > having some sort of support for byte sized data. It shouldn't be that tough > to map most rep clauses onto that sort of machine. Even if all machines had 8-bit bytes and 32-bit words, you still want different code depending on whether a bit-field crosses a word boundary. Different code = complexity. As you say, endianness is still a problem. And I'm currently supporting an Ada compiler for a machine whose Storage_Unit = 32, rather than the more common 8. By the way, nesting of records within records and arrays also introduces complexity (again, if you require efficiency). I once worked on an Ada prototype compiler (around 1982), which ignored efficiency, and did everything in one general way that always worked. The generated code was intolerable. For example, to do "X := Y;" where X and Y are of type Integer, it copied each of the 36 bits individually (it was a PDP-10, which is a 36-bit word-addressable machine). Totally useless. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 20:58 ` RISC Robert A Duff @ 2001-03-19 16:17 ` Marin David Condic 2001-03-19 16:45 ` RISC Florian Weimer 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-19 16:17 UTC (permalink / raw) Ahhhhh, the DEC 10! In my circles, we always celebrate December 10th in honor of the DEC 10. :-) That was my very first computer - programming it from loud, shaky teletypes and occasionally punchcards. TOPS-10 was a really spiffy operating system too. Years ago when Ada was just a glimmer in the eyes of many, I was really hoping someone would make an Ada compiler for the DEC 10 - mostly because I had free access to one and this was in a time when a "real" computer could cost you a fortune. But of course, with DEC abandoning the technology, nobody wanted to target the DEC 10. What a shame. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccae6lqvmf.fsf@world.std.com... > I once worked on an Ada prototype compiler (around 1982), which ignored > efficiency, and did everything in one general way that always worked. > The generated code was intolerable. For example, to do "X := Y;" where > X and Y are of type Integer, it copied each of the 36 bits individually > (it was a PDP-10, which is a 36-bit word-addressable machine). > Totally useless. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 16:17 ` RISC Marin David Condic @ 2001-03-19 16:45 ` Florian Weimer 2001-03-19 17:14 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Florian Weimer @ 2001-03-19 16:45 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Ahhhhh, the DEC 10! In my circles, we always celebrate December 10th in > honor of the DEC 10. :-) Current GCC is being ported to the PDP-10. Perhaps one day, your dream of an Ada compiler for this architecture will come true. ;-) ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 16:45 ` RISC Florian Weimer @ 2001-03-19 17:14 ` Marin David Condic 2001-03-19 17:33 ` RISC Florian Weimer 2001-03-21 5:57 ` RISC Lao Xiao Hai 0 siblings, 2 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-19 17:14 UTC (permalink / raw) That would be very interesting. But *more* interesting would be "Who is still using a PDP-10 and where is it located?" (My best guess would be a museum. :-) Or even "Why???" Porting GCC to it would be cool - but who is doing it and why? Maybe we can get a port of GCC to the IBM 1401 while we're at it? The architecture was pretty neat and was possibly responsible for the "look and feel" of a lot of other systems. The MS-DOS window always reminded me of the look and feel of TOPS-10. You think someone involved with that used to work with a DEC 10? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Florian Weimer" <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote in message news:tgitl5yagd.fsf@mercury.rus.uni-stuttgart.de... > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > > > Ahhhhh, the DEC 10! In my circles, we always celebrate December 10th in > > honor of the DEC 10. :-) > > Current GCC is being ported to the PDP-10. Perhaps one day, your > dream of an Ada compiler for this architecture will come true. ;-) ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 17:14 ` RISC Marin David Condic @ 2001-03-19 17:33 ` Florian Weimer 2001-03-21 5:57 ` RISC Lao Xiao Hai 1 sibling, 0 replies; 82+ messages in thread From: Florian Weimer @ 2001-03-19 17:33 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > That would be very interesting. But *more* interesting would be "Who is > still using a PDP-10 and where is it located?" (My best guess would be a > museum. :-) Compuserve is customer of SC Group, which still manufactures PDP-10 compatible machines, see http://www.scgroup.com/sc40.html and http://www.scgroup.com/customers.html. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 17:14 ` RISC Marin David Condic 2001-03-19 17:33 ` RISC Florian Weimer @ 2001-03-21 5:57 ` Lao Xiao Hai 1 sibling, 0 replies; 82+ messages in thread From: Lao Xiao Hai @ 2001-03-21 5:57 UTC (permalink / raw) Marin David Condic wrote: > The architecture was pretty neat and was possibly responsible for the "look > and feel" of a lot of other systems. The MS-DOS window always reminded me of > the look and feel of TOPS-10. You think someone involved with that used to > work with a DEC 10? I have read that Bill Gates once wrote programs for the DEC-10. More important, many of the ideas Gary Kildall introduced into CP/M originated in the DEC-10. Of course, those ideas were adopted by Tim Patterson when he invented what would be appropriated by Bill Gates as MS-DOS. The heritage of the DEC-10 does live on in the many operating systems that have evolved through Kildall's work. Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 19:02 ` RISC Marin David Condic 2001-03-16 20:58 ` RISC Robert A Duff @ 2001-03-16 22:19 ` Ted Dennison 1 sibling, 0 replies; 82+ messages in thread From: Ted Dennison @ 2001-03-16 22:19 UTC (permalink / raw) In article <98to0v$6d2$1@nh.pace.co.uk>, Marin David Condic says... > >Yes - this would be *very* nice! There are often in data streams things of >uncertain quantity which become very hard to represent in the usual Ada >structures. You get things like "This16 bit word will tell you how many >doohickies will follow...." and it will be surrounded by fixed data. It >doesn't map well to records - but maybe some other structure could be >created to handle it. Typically, you'll end up "rolling-your-own" by >building some kind of dynamic data structure to hold these things. You >construct the data structure as you read the data in. Not that hard to do, >but it would be *really* nice to describe one of these things at a high >level and just have all that done for you by the compiler. ASN.1 had a lot of this type of stuff. Take the standard "length octet" for instance (...please!). Bit 8 selects between "short form" and "long form". In "short form" the other 7 bits indicate the length of the contents. In "long form", the other 7 bits indicate how many of the following bytes are used to determinte the length of the rest of the contents. (Remember, no problem can't be solved by another level of indirection...) However, if bit 8 is on and the rest of the bits are off, then it indicates that we are using "indefinite form", where two terminator octets at the end of the contents determine the length. A week of wrestling with this kind of stuff several years ago was enough to convince me that there are always going to be some formats that just cannot be nicely handled at a high-level with something like a rep clause. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 17:10 ` RISC Robert A Duff 2001-03-16 19:02 ` RISC Marin David Condic @ 2001-03-16 19:13 ` Laurent Guerby 2001-03-16 20:30 ` RISC Robert A Duff 2001-03-16 20:51 ` RISC Ole-Hjalmar Kristensen 2 siblings, 1 reply; 82+ messages in thread From: Laurent Guerby @ 2001-03-16 19:13 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > There are also a lot of things that rep clauses just can't express. Eg, > TCP/IP protocols often have data structures defined like "a count byte, > followed by an array of sub-records" where the count gives the number of > sub-records, or the number of bytes including (or not including) the > count byte itself. I would like to have a language that could describe > that sort of thing at a reasonably high level. For the "non including" case, a discriminated record should do the job in Ada. (OK, it fails for more complicated stuff.) > - Bob -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 19:13 ` RISC Laurent Guerby @ 2001-03-16 20:30 ` Robert A Duff 0 siblings, 0 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-16 20:30 UTC (permalink / raw) Laurent Guerby <guerby@acm.org> writes: > Robert A Duff <bobduff@world.std.com> writes: > > There are also a lot of things that rep clauses just can't express. Eg, > > TCP/IP protocols often have data structures defined like "a count byte, > > followed by an array of sub-records" where the count gives the number of > > sub-records, or the number of bytes including (or not including) the > > count byte itself. I would like to have a language that could describe > > that sort of thing at a reasonably high level. > > For the "non including" case, a discriminated record should do the job > in Ada. (OK, it fails for more complicated stuff.) If it's a count of bytes, a discrim record doesn't work. The discrim has to be a count of number of array elements. Also, you can't control where the array goes. And if there's more data after the array, you're in trouble. And some compilers want to put dope fields in the midst of discriminated records. And some compilers allocate some record fields as a pointer to a separately-allocated thing. I actually think Ada takes the wrong approach by letting you (or making you) specify individual bit numbers. I would define a canonical record layout algorithm, and a pragma that requests the canonical layout. (Or two canonical ones -- canonical tightly packed, and canonical not crossing boundaries. Or something like that.) The default should be that the compiler can do what it likes (which presumably is the most efficient thing, subject to keeping compiler complexity within reason). - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 17:10 ` RISC Robert A Duff 2001-03-16 19:02 ` RISC Marin David Condic 2001-03-16 19:13 ` RISC Laurent Guerby @ 2001-03-16 20:51 ` Ole-Hjalmar Kristensen 2 siblings, 0 replies; 82+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-03-16 20:51 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: <stuff deleted> > There are also a lot of things that rep clauses just can't express. Eg, > TCP/IP protocols often have data structures defined like "a count byte, > followed by an array of sub-records" where the count gives the number of > sub-records, or the number of bytes including (or not including) the > count byte itself. I would like to have a language that could describe > that sort of thing at a reasonably high level. > > - Bob Perhaps something like the facilities in Haskell would be a good starting point? -- Kabelsalat ist gesund. Ole-Hj. Kristensen ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 15:09 ` RISC Tucker Taft 2001-03-16 17:10 ` RISC Robert A Duff @ 2001-03-16 18:33 ` Marin David Condic 2001-03-16 20:45 ` RISC Robert A Duff 1 sibling, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-16 18:33 UTC (permalink / raw) I know its sometimes hard to deal with rep clauses from a compiler writer's perspective. 99.44% of the time I really don't care what the compiler does with a record and hope that the representation chosen makes for easy optimization. Its just that from the perspective of a developer with concerns for interfacing to the outside world, it becomes *really* important to be sure you get what you need. Perhaps there needs to be some kind of compromise? Typically, I am only interested in the representation clause on a record if the record is going to hold data for I/O (usually a communication path) or it represents some electronic device (registers, ports, special hardware, etc.) So mostly, I'm going to move data into it and extract data out of it. Some other structure that is not used for anything computational may be a suitable answer. For example, JOVIAL had something called a "compool" (IIRC?) that was similar to a Fortran common block. We used to get superb control over the layout of a compool. - making things span word boundaries, etc. It obviously wasn't the same as a record type and didn't have to support the semantics of an Ada record, so maybe it was easier for the compiler to support it with strange representations? If there was a similar structure in Ada - one that had limited use to spare the compiler grief - maybe this would suffice for most of the uses where representations become a big deal? type T is table Some_Field : Yadayadayada; --rep controlled similar to a record. end table ; And the only allowed operations on a table are assignments to/from fields or assignments to/from the whole structure. (No math or other stuff - just data motion) Would something like this take the burden off of the compiler writer? I'm not sure if I'd need tagged tables or not. I know I don't mind where you put the tag - as long as I can find out where the tag is so I can work around it. Does the presence of a tag and class-wide operations provide a problem? (Again assuming that all you ever have to support is assignment of data.) I'm not sure there might not be a better way - such as through some sort of pragma on record types - to ease the burden, but I know that I could live with some restrictions on the records for which I want to control representation. I just need some mechanism to guarantee I can make my memory representation match things outside of the language. Just an idea..... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Tucker Taft" <stt@averstar.com> wrote in message news:3AB22CB2.E8A851A5@averstar.com... > This is my cue to pipe up with the Compiler Writer's Lament. > Rep clauses are difficult to support because every special case > makes a compiler more complicated and more buggy, and makes > optimization harder. So compilers really "want" to do everything > one way if possible, and then optimize the heck out of that. <snip> ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 18:33 ` RISC Marin David Condic @ 2001-03-16 20:45 ` Robert A Duff 2001-03-17 1:13 ` RISC Randy Brukardt 2001-03-19 16:34 ` RISC Marin David Condic 0 siblings, 2 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-16 20:45 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > And the only allowed operations on a table are assignments to/from fields or > assignments to/from the whole structure. (No math or other stuff - just data > motion) Would something like this take the burden off of the compiler > writer? I don't think it helps much. If you do X.Y * A.B, the compiler needs to extract bit fields for Y and B into registers. Once they're in registers, doing the multiply is no problem. Disallowing that multiply would not simplify. I suppose there are some interactions if you try to optimize: eg, if I write "if This.X = That.X then ..." I'd like to see the shifts normally used to access the bitfield X optimized away. But it's still no help to disallow it. The complexity that Tucker was talking about is in generating code for reading and writing components. If you want any reasonable kind of efficiency, and you insist on generality, the compiler needs to know several ways of accessing components: those that are nicely aligned on storage unit boundaries, those that are bit fields within a single word, those that are bit fields crossing word boundaries, those that are bit fields that are bigger than a word, &c. And it's machine dependent (some machines have double-word shifts and whatnot), which means the complexity is multiplied across all targets supported. But it's not *that* complicated (at least the complexity is fairly localized), and as I said, I think it's worth it. Anyway, I don't like these kinds of restrictions in a language design. It's annoying to the programmer, and too often the restriction doesn't actually help the compiler -- in fact, it makes the compiler's job harder, because it has to check the restriction rules. Think of the restrictions on array indices in early versions of FORTRAN -- a variable, a variable plus a literal, and a few others, based on the indexing modes of long-forgotten hardware. For the compiler, it's actually simpler if array indices are just general expressions. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 20:45 ` RISC Robert A Duff @ 2001-03-17 1:13 ` Randy Brukardt 2001-03-19 16:34 ` RISC Marin David Condic 1 sibling, 0 replies; 82+ messages in thread From: Randy Brukardt @ 2001-03-17 1:13 UTC (permalink / raw) Robert A Duff wrote in message ... >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > >> And the only allowed operations on a table are assignments to/from fields or >> assignments to/from the whole structure. (No math or other stuff - just data >> motion) Would something like this take the burden off of the compiler >> writer? > >I don't think it helps much. If you do X.Y * A.B, the compiler needs to >extract bit fields for Y and B into registers. Once they're in >registers, doing the multiply is no problem. Disallowing that multiply >would not simplify. For records, I agree, it doesn't matter much. For arrays, it certainly would be a lot easier if you didn't have to deal with slices and relationals on arrays of discretes. Those (and generic formal types) are the reason that Janus/Ada doesn't support 'Component_Size very well. I've never been able to figure out any sane way to implement an arbitrary slice of a packed boolean array assigned into another packed boolean array. Any particular case isn't too hard, but the general case looks like: Bar (Start .. End) := Foo (Start+Offset .. End+Offset); About the only thing I can see to do is punt and do it a component at a time; but the performance would be abismal. Still, Bob is right that "helpful" restrictions often turn out to be not helpful. The obvious example is the restrictions on "others" clauses in aggregates in Ada 83. We spent more effort trying to implement the restrictions than we did implementing the aggregates in the first place (I mistakenly implemented nearly full support for arbitrary "others" clauses before discovering that it wasn't required or allowed.) Randy. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 20:45 ` RISC Robert A Duff 2001-03-17 1:13 ` RISC Randy Brukardt @ 2001-03-19 16:34 ` Marin David Condic 2001-03-19 17:49 ` RISC Robert A Duff 1 sibling, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-19 16:34 UTC (permalink / raw) Werll, not being a compiler kind of guy, I don't really know what the problems are. I think I understand what you're getting at - that the reading and writing of individual fields can cause all sorts of problems for efficient compilation. Hence my notion of restricting usage isn't really going to help. I suppose it is worth pointing out that in the *bulk* of the cases, a rep clause isn't going to ask for things that are going to be hard or inefficient. You use the rep clause to give yourself a nice, warm, fuzzy feeling that somehow that 32 bit, longword aligned integer is going to *always* fall in this position within the record so you're not scared that a new compiler version is going to go move it on you and your I/O with some other device is now screwed up. (I've had *SERIOUS* troubles with compilers when asking for very simple things, like putting various record fields on 16 bit boundaries for a machine that supports 16 bit data. But Noooooooo! Data had to fall on 32 bit boundaries or the compiler puked.) In the cases where we have to deal with the perversities of some hardware engineer who never worked on a compiler or had to build software to deal with his strange representation of data, I guess I'd be willing to live with inefficient code so long as I had some means of plugging in the data in and impacting the device properly. If someone stuck an odd sized integer(1) into some location that spanned longword boundaries and I've somehow got to plug a number in there, I'd rather have an inefficient way of doing it than getting told by the compiler that it won't do that at all because it is a dumb idea - or simply get confused and think I was asking for a representation that can't be done. (1) I once had a serious disput with a casino roulette wheel operator over what I considered to be an "odd" number. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccbsr1qw7b.fsf@world.std.com... > The complexity that Tucker was talking about is in generating code for > reading and writing components. If you want any reasonable kind of > efficiency, and you insist on generality, the compiler needs to know > several ways of accessing components: those that are nicely aligned on > storage unit boundaries, those that are bit fields within a single word, > those that are bit fields crossing word boundaries, those that are bit > fields that are bigger than a word, &c. And it's machine dependent > (some machines have double-word shifts and whatnot), which means the > complexity is multiplied across all targets supported. > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 16:34 ` RISC Marin David Condic @ 2001-03-19 17:49 ` Robert A Duff 0 siblings, 0 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-19 17:49 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Werll, not being a compiler kind of guy, I don't really know what the > problems are. I think I understand what you're getting at - that the reading > and writing of individual fields ... and slices >...can cause all sorts of problems for > efficient compilation. Hence my notion of restricting usage isn't really > going to help. > In the cases where we have to deal with the perversities of some hardware > engineer who never worked on a compiler or had to build software to deal > with his strange representation of data, I guess I'd be willing to live with > inefficient code ... Yes, you're willing to live with inefficient code in *those* cases, and you have no choice -- those cases are inherently inefficient. But I'll bet you're *not* willing to live with inefficiency for loading a 32-bit, properly aligned integer. So the compiler has to treat that as a special case (ie, generate different code for these two scenarios). - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 20:23 RISC chris.danx 2001-03-14 21:57 ` RISC Tucker Taft 2001-03-15 12:37 ` RISC chris.danx @ 2001-03-16 20:08 ` chris.danx 2001-03-16 20:31 ` RISC Marin David Condic 2001-03-16 22:27 ` RISC chris.danx 2001-03-22 20:11 ` RISC chris.danx 4 siblings, 1 reply; 82+ messages in thread From: chris.danx @ 2001-03-16 20:08 UTC (permalink / raw) Maybe i'm being stupid, please feel free to inform me if this is so, but i'll ask anyway. I know functions are allowed to throw exceptions in Ada. What i want to know is acceptable practice? I use exceptions with procedures, no problem, but someone -- can't remember who exactly, it was ages ago -- suggested it's bad practice! What do you think? If i remember correctly i think this related to C++, or something, so maybe it's irrelevant to Ada. Just curious, Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 20:08 ` RISC chris.danx @ 2001-03-16 20:31 ` Marin David Condic 2001-03-17 21:51 ` RISC Robert A Duff 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-16 20:31 UTC (permalink / raw) No question is stupid if you don't know the answer. There is no reason you *can't* raise an exception in a function. ("Throw" is the C++ terminology - "Raise" is the Ada terminology) There are conditions under which a function will generate an exception on its own even if you don't explicitly raise one. (Example: Hit the end of a function without returning a result. This will raise "Program_Error" - if I remember correctly.) The question "Is it good practice to raise exceptions in functions?" is fair. The answer is: "It Depends..." If you encounter a condition that is truly "exceptional" and/or it represents some sort of erroneous condition, then raising an exception is fair to do. Example: You write a function for which some combination of parameters makes no sense or leaves the function undefined. Go ahead and raise an exception. If you encounter some sort of normal, expected condition and use an exception for some sort of transfer of control, this is generally considered impolite and/or bad form. Example: You design a function to raise an exception to accomplish a loop exit when you hit the terminal condition for the loop. When to raise an exception will also depend on the nature of your system. If the system encounters an error is it proper for the program to stop running? If not, then you may not want to raise the exception - or at least guarantee you have a handler for all exceptions. Again, "It Depends." Its hard to come up with absolute rules since it often requires subjective, artistic judgements. Just keep in mind that the intention is to have a mechanism that deals with *errors* - not anticipated conditions that can be accommodated with some sort of "normal" processing. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "chris.danx" <chris.danx@ntlworld.com> wrote in message news:Cous6.1406$lC5.401322@news2-win.server.ntlworld.com... > Maybe i'm being stupid, please feel free to inform me if this is so, but > i'll ask anyway. > > I know functions are allowed to throw exceptions in Ada. What i want to > know is acceptable practice? I use exceptions with procedures, no problem, > but someone -- can't remember who exactly, it was ages ago -- suggested it's > bad practice! What do you think? If i remember correctly i think this > related to C++, or something, so maybe it's irrelevant to Ada. > > Just curious, > Chris Campbell > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 20:31 ` RISC Marin David Condic @ 2001-03-17 21:51 ` Robert A Duff 2001-03-18 6:37 ` RISC Charles Hixson 2001-03-19 16:45 ` RISC Marin David Condic 0 siblings, 2 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-17 21:51 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Its hard to come up with absolute rules since it often requires subjective, > artistic judgements. Just keep in mind that the intention is to have a > mechanism that deals with *errors* - not anticipated conditions that can be > accommodated with some sort of "normal" processing. Which leaves open the definition of "error". Different folks have different notions of error. I think the point of exceptions is that whether a given condition is an "error" depends on your point of view. Eg, a data structure package that has a Remove_Item operation: if the data structure is empty, that's an error, and an exception is appropriate. But from the point of view of the client, this situation might be "normal" or might be a bug -- it's the programmer's choice. Another way to look at it is that the point of exceptions is to separate the code that *detects* errors from the code that *handles* those situations. If the code that detects something knows what to do about it, then exceptions aren't necessary -- that code can just have an 'if' statement that checks the condition, and handles the situation in the 'then' part. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-17 21:51 ` RISC Robert A Duff @ 2001-03-18 6:37 ` Charles Hixson 2001-03-19 15:42 ` RISC Robert A Duff 2001-03-19 17:02 ` RISC Marin David Condic 2001-03-19 16:45 ` RISC Marin David Condic 1 sibling, 2 replies; 82+ messages in thread From: Charles Hixson @ 2001-03-18 6:37 UTC (permalink / raw) Robert A Duff wrote: > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > >> Its hard to come up with absolute rules since it often requires >> subjective, artistic judgements. Just keep in mind that the intention is >> to have a mechanism that deals with *errors* - not anticipated conditions >> that can be accommodated with some sort of "normal" processing. > >.... > Another way to look at it is that the point of exceptions is to separate > the code that *detects* errors from the code that *handles* those > situations. If the code that detects something knows what to do about > it, then exceptions aren't necessary -- that code can just have an 'if' > statement that checks the condition, and handles the situation in the > 'then' part. > > - Bob > Is the problem that exceptions are expensive, or that exceptions violate localization? Or something else? E.g.: Should EOF detection be done with an exception? It's usuaual, but expected. I think of encountering an EOF and an unusual condition, and it's nice to be able to automatically check for it whenever a read happens without explicitly calling on an eof() function. Java rather expects that procedures will throw exceptions. I don't know C++ well enough to comment. Python seems to believe that exceptions are quite reasonable. Eiffel thinks that exceptions should be handled within the same routine that defines them. Etc. I think that this is a language specific issue. My impression was that Ada exceptions were intended to handle unusual cases (exceptional cases). That they were slightly more expensive to raise than a local branch would be, but that they were slightly cheaper if no exceptional case was detected. And that they should be handled as close to the routine that raised them as possible. Preferably within the routine. But I would hardly call myself an expert at Ada. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-18 6:37 ` RISC Charles Hixson @ 2001-03-19 15:42 ` Robert A Duff 2001-03-19 17:02 ` RISC Marin David Condic 1 sibling, 0 replies; 82+ messages in thread From: Robert A Duff @ 2001-03-19 15:42 UTC (permalink / raw) Charles Hixson <charleshixsn@earthlink.net> writes: > Robert A Duff wrote: > > > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > > > >> Its hard to come up with absolute rules since it often requires > >> subjective, artistic judgements. Just keep in mind that the intention is > >> to have a mechanism that deals with *errors* - not anticipated conditions > >> that can be accommodated with some sort of "normal" processing. > > > >.... > > Another way to look at it is that the point of exceptions is to separate > > the code that *detects* errors from the code that *handles* those > > situations. If the code that detects something knows what to do about > > it, then exceptions aren't necessary -- that code can just have an 'if' > > statement that checks the condition, and handles the situation in the > > 'then' part. > > > > - Bob > > Is the problem that exceptions are expensive, or that exceptions violate > localization? Or something else? I'm not sure which problem you're referring to. I was just trying to explain the point of exceptions (ie, why do we have exceptions instead of just if statements and whatnot). I wasn't trying to point out any problem. > E.g.: Should EOF detection be done with an exception? It's usuaual, but > expected. I think of encountering an EOF and an unusual condition, and > it's nice to be able to automatically check for it whenever a read happens > without explicitly calling on an eof() function. I prefer the function in the EOF case. > Java rather expects that procedures will throw exceptions. I don't know > C++ well enough to comment. Python seems to believe that exceptions are > quite reasonable. Eiffel thinks that exceptions should be handled within > the same routine that defines them. Etc. I think that this is a language > specific issue. True. But as a language designer by nature, I tend to think about "how should I design an exception facility", rather than just, "how should exceptions be used in this particular language", given the biases of the language designer. > My impression was that Ada exceptions were intended to handle unusual cases > (exceptional cases). That they were slightly more expensive to raise than > a local branch would be, but that they were slightly cheaper if no > exceptional case was detected. Sort of true, except for the "slightly" part. In a good Ada implementation, it is enormously more expensive to raise an exception than to do an if_statement or whatever. Perhaps 1,000 times more expensive (just a wild guess). If the exceptional case is *not* detected, you still have to execute the compare instruction (or whatever) that would have detected it, so I see no difference there (unless you're talking about something like overflow, which can be detected by the hardware "for free" on some machines). This efficiency trade-off is because of the intended use of exceptions, not the other way around. >... And that they should be handled as close to > the routine that raised them as possible. Preferably within the routine. I don't agree. If it's handled in the routine itself, why raise and handle an exception? Why not just write: if X.Length < 1 then Do_Something_About_It; Exceptions are for the case where the "if X.Length < 1 then" is in a different procedure than the "Do_Something_About_It;", because the procedure that detects the error doesn't *know* what to do about it. I'm not talking about efficiency here -- it would be possible to implement very-local handlers as efficiently as an if statement / conditional jump. But nobody does that, because it's not the way exceptions should be used. The "as close to" part of what you wrote is often true. But there are certainly cases of handling exceptions very far away: the main program might handle "others", and then crash gracefully -- it has no idea where the exception came from. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-18 6:37 ` RISC Charles Hixson 2001-03-19 15:42 ` RISC Robert A Duff @ 2001-03-19 17:02 ` Marin David Condic 2001-03-19 17:45 ` RISC Robert A Duff 1 sibling, 1 reply; 82+ messages in thread From: Marin David Condic @ 2001-03-19 17:02 UTC (permalink / raw) It isn't an efficiency issue. Its more of a "design philosophy" issue. If you are working with systems that have a really high reliability requirement, you'll get various arguments for and against using exceptions. (Hard to mathematically "prove" the code, vs "that's what exceptions are for!" arguments.) Exceptions can be viewed as a sort of "limited/controlled goto" - and as such they can pose hazards to good software design. For example, the Text_IO package will raise an exception if you try to read past the end of a file because it has no way of knowing what you are attempting to do or why. It just knows you asked it to do the impossible so it properly throws up its hands, curses you in exasperation and raises an exception. However, *your* code ought to know what it is doing with the file and should properly be checking for End_Of_File as an anticipated condition. You might protect yourself by trapping any EOF exceptions because you may have made a programming error and in some corner case you attempt to read past the end of the file. Your code should be raising exceptions in similar circumstances - when it becomes clear that some condition has occurred that is beyond the understanding and the *responsibility* of the module in which it is raised. A good example is a function that is undefined for some combination of parameters. The function in effect says "I have no idea why you sent me this combination of numbers and there really isn't anyting intelligent I can do with them to fix the problem and let you press on, so I'm going to raise an exception that you cannot ignore so you are aware that you probably made a mistake." The calling code should be trapping exceptions (or not) as a means of catching unexpected conditions - but not as a normal transfer of control mechanism. (You would consider it "bad form" to terminate your programs by dividing by zero, wouldn't you? Same concept here.) And remember that raising & handling exceptions may or may not be done depending on the nature of the system. You have to consider this in the requirements/design phases of the system & plan accordingly. (id est, take a decision about what exception philosophy should be followed for *this* application.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:vIYs6.6150$227.669029@newsread2.prod.itd.earthlink.net... > Robert A Duff wrote: > > > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > > > >> Its hard to come up with absolute rules since it often requires > >> subjective, artistic judgements. Just keep in mind that the intention is > >> to have a mechanism that deals with *errors* - not anticipated conditions > >> that can be accommodated with some sort of "normal" processing. > > > >.... > > Another way to look at it is that the point of exceptions is to separate > > the code that *detects* errors from the code that *handles* those > > situations. If the code that detects something knows what to do about > > it, then exceptions aren't necessary -- that code can just have an 'if' > > statement that checks the condition, and handles the situation in the > > 'then' part. > > > > - Bob > > > > Is the problem that exceptions are expensive, or that exceptions violate > localization? Or something else? > > E.g.: Should EOF detection be done with an exception? It's usuaual, but > expected. I think of encountering an EOF and an unusual condition, and > it's nice to be able to automatically check for it whenever a read happens > without explicitly calling on an eof() function. > > Java rather expects that procedures will throw exceptions. I don't know > C++ well enough to comment. Python seems to believe that exceptions are > quite reasonable. Eiffel thinks that exceptions should be handled within > the same routine that defines them. Etc. I think that this is a language > specific issue. > > My impression was that Ada exceptions were intended to handle unusual cases > (exceptional cases). That they were slightly more expensive to raise than > a local branch would be, but that they were slightly cheaper if no > exceptional case was detected. And that they should be handled as close to > the routine that raised them as possible. Preferably within the routine. > But I would hardly call myself an expert at Ada. > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 17:02 ` RISC Marin David Condic @ 2001-03-19 17:45 ` Robert A Duff 2001-03-19 18:48 ` RISC Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Robert A Duff @ 2001-03-19 17:45 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Exceptions can be viewed as a sort of "limited/controlled goto" - and as > such they can pose hazards to good software design. I'd say it's the other way around: goto's are more limited that raising an exception, because with a goto, you can tell statically where you're going to, whereas an exception is a goto to a dynamically determined label. - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 17:45 ` RISC Robert A Duff @ 2001-03-19 18:48 ` Marin David Condic 0 siblings, 0 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-19 18:48 UTC (permalink / raw) Depends on perspective. A goto can goto *anywhere* in the code. (almost) An exception can only leap to certain well defined parts of the code with rather specific purposes. I can see your point - gotos have a single specific destination. (Unless you have the Cobol "alter" statement at work for you.) Exceptions can goto a variety of locations depending on context. My point was more from the static usage perspective in that exception handlers can't appear just anywhere and exceptions can't jump to just anywhere. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wcc4rwp3b5j.fsf@world.std.com... > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > > > Exceptions can be viewed as a sort of "limited/controlled goto" - and as > > such they can pose hazards to good software design. > > I'd say it's the other way around: goto's are more limited that raising > an exception, because with a goto, you can tell statically where you're > going to, whereas an exception is a goto to a dynamically determined > label. > > - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-17 21:51 ` RISC Robert A Duff 2001-03-18 6:37 ` RISC Charles Hixson @ 2001-03-19 16:45 ` Marin David Condic 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-19 16:45 UTC (permalink / raw) Good points made here. That's kind of why I observed that it is more of an "art" than a "science". If an engineer has a good sense of what exceptions are for and how they should be used, he's likely to do a good job with their usage. However, there aren't a bunch of clear cut rules to apply that always guide you to proper use of exceptions. I suspect it would be easier to write a set of rules for proper usage of the goto statement than it would be to write rules for exceptions. Start with "never" and then add the handful of cases where it makes sense as exceptions to the "never" rule. I can't quite get to the same point with exceptions.... (But how's *that* for flame bait? :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert A Duff" <bobduff@world.std.com> wrote in message news:wcczoek12ur.fsf@world.std.com... > Which leaves open the definition of "error". Different folks have > different notions of error. > > I think the point of exceptions is that whether a given condition is an > "error" depends on your point of view. Eg, a data structure package > that has a Remove_Item operation: if the data structure is empty, that's > an error, and an exception is appropriate. But from the point of view > of the client, this situation might be "normal" or might be a bug -- > it's the programmer's choice. > > Another way to look at it is that the point of exceptions is to separate > the code that *detects* errors from the code that *handles* those > situations. If the code that detects something knows what to do about > it, then exceptions aren't necessary -- that code can just have an 'if' > statement that checks the condition, and handles the situation in the > 'then' part. > > - Bob ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-14 20:23 RISC chris.danx ` (2 preceding siblings ...) 2001-03-16 20:08 ` RISC chris.danx @ 2001-03-16 22:27 ` chris.danx 2001-03-17 2:49 ` RISC Jeffrey Carter 2001-03-19 9:43 ` RISC Martin Dowie 2001-03-22 20:11 ` RISC chris.danx 4 siblings, 2 replies; 82+ messages in thread From: chris.danx @ 2001-03-16 22:27 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1213 bytes --] Two quickies! I hope! Does Ada have routines for displaying numbers in Hex or Octal (preferably Hex)? I would write a recursive function to do this, but recursion isn't something i'm confident with. It'd go something like divide by 16 taking remainder each time and append the result to front of string, stopping when number is 0, i think. It'd be nice if Ada did it for us though. Most of the books only mention mod/integer display in decimal, and i can't afford that �57.00 book covering the 'whole' of the Ada language and standard libraries. {books are really expensive -- i've been out �400-�500 on books this academic year alone. I moan too much!!!} I'm using mod types to simulate registers in the RISC machine. I'm about to implement arithmetic operations but i've thought of a problem. How do i detect overflow? e.g. say it was 1 byte reg 25*158 is too big. 12+254 is too big also. but mod types wrap round, so how do i detect the overflow? This is a bugger, cos' i've implemented quite a bit of the RISC computers base like Registers and Memory (thanks to Tucker Taft for the VMem like suggestion, it's almost working). Thanks for everyone's help, Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 22:27 ` RISC chris.danx @ 2001-03-17 2:49 ` Jeffrey Carter 2001-03-19 9:43 ` RISC Martin Dowie 1 sibling, 0 replies; 82+ messages in thread From: Jeffrey Carter @ 2001-03-17 2:49 UTC (permalink / raw) "chris.danx" wrote: > > Does Ada have routines for displaying numbers in Hex or Octal (preferably > Hex)? Check out the Base parameter to Put in the various Ada.Text_IO.<numeric-class>_IO generic packages (ARM A.10). -- Jeff Carter "I waggle my private parts at your aunties." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 22:27 ` RISC chris.danx 2001-03-17 2:49 ` RISC Jeffrey Carter @ 2001-03-19 9:43 ` Martin Dowie 2001-03-19 11:06 ` RISC chris.danx 2001-03-28 22:24 ` RISC chris.danx 1 sibling, 2 replies; 82+ messages in thread From: Martin Dowie @ 2001-03-19 9:43 UTC (permalink / raw) I had a similar problem recently when I had to mimic unsigned 64 bits with only unsigned 32 bits available. For addition and subtract it is fairly easy. e.g. a = 255, b = 1 c = a + b if c < a then overflow as it has wrapped similarly for subtraction with > instead of <. I only required +/- support, so I'm afraid I have no solutions for * or / :-( The long-hand way for multiplications would be to add e.g. a = 90, b = 3 c = 0 for I in 1 .. b loop c = c + a if c < a then overflow as it has wrapped end loop not very efficient... Sorry, no ideas spring to mind for division... chris.danx <chris.danx@ntlworld.com> wrote in message news:qrws6.3335$bL.360000@news6-win.server.ntlworld.com... > Two quickies! I hope! > >[snip] > > I'm using mod types to simulate registers in the RISC machine. I'm about to > implement arithmetic operations but i've thought of a problem. How do i > detect overflow? > > e.g. > say it was 1 byte reg > > 25*158 is too big. > > 12+254 is too big also. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 9:43 ` RISC Martin Dowie @ 2001-03-19 11:06 ` chris.danx 2001-03-28 22:24 ` RISC chris.danx 1 sibling, 0 replies; 82+ messages in thread From: chris.danx @ 2001-03-19 11:06 UTC (permalink / raw) Thanks for that, Chris Campbell "Martin Dowie" <martin.dowie@gecm.com> wrote in message news:3ab5d2a4$1@pull.gecm.com... > I had a similar problem recently when I had to mimic unsigned 64 bits with > only > unsigned 32 bits available. > > For addition and subtract it is fairly easy. e.g. > > a = 255, b = 1 > c = a + b > if c < a then overflow as it has wrapped > > similarly for subtraction with > instead of <. > > I only required +/- support, so I'm afraid I have no solutions for * or / > :-( > > The long-hand way for multiplications would be to add e.g. > a = 90, b = 3 > c = 0 > for I in 1 .. b loop > c = c + a > if c < a then overflow as it has wrapped > end loop > > not very efficient... > > Sorry, no ideas spring to mind for division... > > chris.danx <chris.danx@ntlworld.com> wrote in message > news:qrws6.3335$bL.360000@news6-win.server.ntlworld.com... > > Two quickies! I hope! > > > >[snip] > > > > I'm using mod types to simulate registers in the RISC machine. I'm about > to > > implement arithmetic operations but i've thought of a problem. How do i > > detect overflow? > > > > e.g. > > say it was 1 byte reg > > > > 25*158 is too big. > > > > 12+254 is too big also. > > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-19 9:43 ` RISC Martin Dowie 2001-03-19 11:06 ` RISC chris.danx @ 2001-03-28 22:24 ` chris.danx 2001-03-29 0:52 ` RISC Corey Ashford 2001-03-29 12:42 ` RISC John English 1 sibling, 2 replies; 82+ messages in thread From: chris.danx @ 2001-03-28 22:24 UTC (permalink / raw) mod types have made some parts of the machine simple but are making arithmetic operations a nightmare. I need to support 2s compliment integers (floats will not feature at all) hence mod types. Taking not of X and add 1, then it's negative. no probs! Problem is with sign and overflow on add, sub, mul, div. Each one must cope with signed nums and unsigned ones -- signal a carry or overflow. I think you can just do add/sub and no worries. Problems arise when i detect overflow, i tried thinking this out, and Martin Dowie pointed out a possible solution that might work but only for unsigned nums. I don't know how to go about this signed ones. I really need to know how to detect overflow for multiplication and division. I also need a way to detect it for add and sub. Maybe Ada has an attribute for this or something, e.g. ... type X is mod 256; ... a : x := 128; a := x + x; ... if a'overflow then ... end if; {i doubt it though!} Can anyone help, Thanks, Chris Campbell "Martin Dowie" <martin.dowie@gecm.com> wrote in message news:3ab5d2a4$1@pull.gecm.com... > I had a similar problem recently when I had to mimic unsigned 64 bits with > only > unsigned 32 bits available. > > For addition and subtract it is fairly easy. e.g. > > a = 255, b = 1 > c = a + b > if c < a then overflow as it has wrapped > > similarly for subtraction with > instead of <. > > I only required +/- support, so I'm afraid I have no solutions for * or / > :-( > > The long-hand way for multiplications would be to add e.g. > a = 90, b = 3 > c = 0 > for I in 1 .. b loop > c = c + a > if c < a then overflow as it has wrapped > end loop > > not very efficient... > > Sorry, no ideas spring to mind for division... > > chris.danx <chris.danx@ntlworld.com> wrote in message > news:qrws6.3335$bL.360000@news6-win.server.ntlworld.com... > > Two quickies! I hope! > > > >[snip] > > > > I'm using mod types to simulate registers in the RISC machine. I'm about > to > > implement arithmetic operations but i've thought of a problem. How do i > > detect overflow? > > > > e.g. > > say it was 1 byte reg > > > > 25*158 is too big. > > > > 12+254 is too big also. > > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-28 22:24 ` RISC chris.danx @ 2001-03-29 0:52 ` Corey Ashford 2001-03-29 12:42 ` RISC John English 1 sibling, 0 replies; 82+ messages in thread From: Corey Ashford @ 2001-03-29 0:52 UTC (permalink / raw) Why not use signed integer types? You'd get overflow detection for free, via a Constraint_Error exception. For example: type X is new Integer range -128 .. 127; for X'size use 8; "chris.danx" <chris.danx@ntlworld.com> wrote in message news:dwtw6.3343$MD6.241100@news6-win.server.ntlworld.com... > mod types have made some parts of the machine simple but are making > arithmetic operations a nightmare. > > I need to support 2s compliment integers (floats will not feature at all) > hence mod types. Taking not of X and add 1, then it's negative. no probs! > Problem is with sign and overflow on add, sub, mul, div. > > Each one must cope with signed nums and unsigned ones -- signal a carry or > overflow. I think you can just do add/sub and no worries. Problems arise > when i detect overflow, i tried thinking this out, and Martin Dowie pointed > out a possible solution that might work but only for unsigned nums. I don't > know how to go about this signed ones. > > I really need to know how to detect overflow for multiplication and > division. I also need a way to detect it for add and sub. Maybe Ada has an > attribute for this or something, > > e.g. ... > type X is mod 256; > ... > a : x := 128; > a := x + x; > ... > if a'overflow then > ... > end if; > > {i doubt it though!} > > Can anyone help, > > > Thanks, > Chris Campbell > > "Martin Dowie" <martin.dowie@gecm.com> wrote in message > news:3ab5d2a4$1@pull.gecm.com... > > I had a similar problem recently when I had to mimic unsigned 64 bits with > > only > > unsigned 32 bits available. > > > > For addition and subtract it is fairly easy. e.g. > > > > a = 255, b = 1 > > c = a + b > > if c < a then overflow as it has wrapped > > > > similarly for subtraction with > instead of <. > > > > I only required +/- support, so I'm afraid I have no solutions for * or / > > :-( > > > > The long-hand way for multiplications would be to add e.g. > > a = 90, b = 3 > > c = 0 > > for I in 1 .. b loop > > c = c + a > > if c < a then overflow as it has wrapped > > end loop > > > > not very efficient... > > > > Sorry, no ideas spring to mind for division... > > > > chris.danx <chris.danx@ntlworld.com> wrote in message > > news:qrws6.3335$bL.360000@news6-win.server.ntlworld.com... > > > Two quickies! I hope! > > > > > >[snip] > > > > > > I'm using mod types to simulate registers in the RISC machine. I'm > about > > to > > > implement arithmetic operations but i've thought of a problem. How do i > > > detect overflow? > > > > > > e.g. > > > say it was 1 byte reg > > > > > > 25*158 is too big. > > > > > > 12+254 is too big also. > > > > > > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-28 22:24 ` RISC chris.danx 2001-03-29 0:52 ` RISC Corey Ashford @ 2001-03-29 12:42 ` John English 1 sibling, 0 replies; 82+ messages in thread From: John English @ 2001-03-29 12:42 UTC (permalink / raw) "chris.danx" wrote: > I really need to know how to detect overflow for multiplication and > division. I also need a way to detect it for add and sub. Maybe Ada has an > attribute for this or something, Overflow detection is easy enough: for addition, you have an overflow iff the sign bits of the values you're adding together are the same but the sign of the result is different (e.g. for i >= 0, j >= 0, i + j < 0). Plan (b): have a handy non-modular type that you can convert your modular values to, then trap constraint errors. ----------------------------------------------------------------- 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] 82+ messages in thread
* Re: RISC 2001-03-14 20:23 RISC chris.danx ` (3 preceding siblings ...) 2001-03-16 22:27 ` RISC chris.danx @ 2001-03-22 20:11 ` chris.danx 2001-03-22 20:51 ` RISC Marin David Condic ` (3 more replies) 4 siblings, 4 replies; 82+ messages in thread From: chris.danx @ 2001-03-22 20:11 UTC (permalink / raw) I've been following the rep clause debate in this thread for sometime. All of a sudden i had the realisation that i didn't have a clue as to what they are. So what are rep clauses? Are there any good books on Ada that cover stuff like direct_io, rep clauses and low level stuff. Most of the books i've got cover ADT/OOP programming and are meant as an introduction to Ada. I'm skint now but the books don't need to be cheap -- but i'd prefer it if they were. Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-22 20:11 ` RISC chris.danx @ 2001-03-22 20:51 ` Marin David Condic 2001-03-22 21:02 ` RISC tmoran ` (2 subsequent siblings) 3 siblings, 0 replies; 82+ messages in thread From: Marin David Condic @ 2001-03-22 20:51 UTC (permalink / raw) A "rep clause" is more properly a "representation clause" (Take time to look over Chapter 13 of the ARM - lots of really interesting stuff there!) Representation clauses take a number of forms - for example to control the size of an Integer type or the underlying numeric values for an Enumeration type. Probably the most commonly used representation clause (and the one that is mostly the target of this sub-thread) is the record representation clause. Employing a little "documentation reuse" I've lifted this example from the ARM: type Program_Status_Word is record System_Mask : Byte_Mask; Protection_Key : Integer range 0 .. 3; Machine_State : State_Mask; Interrupt_Cause : Interruption_Code; Ilc : Integer range 0 .. 3; Cc : Integer range 0 .. 3; Program_Mask : Mode_Mask; Inst_Address : Address; end record; for Program_Status_Word use record System_Mask at 0*Word range 0 .. 7; Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused Machine_State at 0*Word range 12 .. 15; Interrupt_Cause at 0*Word range 16 .. 31; Ilc at 1*Word range 0 .. 1; -- second word Cc at 1*Word range 2 .. 3; Program_Mask at 1*Word range 4 .. 7; Inst_Address at 1*Word range 8 .. 31; end record; for Program_Status_Word'Size use 8*System.Storage_Unit; for Program_Status_Word'Alignment use 8; All this good stuff (and more) *IN THEORY* will allow you to control how your data is represented in memory. This is important when you are using structured data to either directly access hardware or are sending/receiving the data to/from an external source. The problem, as many of us observe, is that there is sometimes a lack of compiler support for all representation clauses. In many of the simple cases you get what you ask for. In more complex cases, you sometimes have the compiler refuse to do what you asked - which is legal, if not helpful. As for books on Ada? My favorite is "Programming in Ada 95" by John Barnes, but that is mostly because his earlier book was the source from which I originally learned Ada83 in depth. (That, and reading the Ada83 LRM). However, there are a lot of good books on the subject. You should try: http://www.adapower.org/ and look under "Books" for several good titles & descriptions. See also: http://www.science-books.net/ada.htm I hope you find this helpful... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "chris.danx" <chris.danx@ntlworld.com> wrote in message news:P%su6.28479$bL.2621853@news6-win.server.ntlworld.com... > I've been following the rep clause debate in this thread for sometime. All > of a sudden i had the realisation that i didn't have a clue as to what they > are. So what are rep clauses? > > Are there any good books on Ada that cover stuff like direct_io, rep clauses > and low level stuff. Most of the books i've got cover ADT/OOP programming > and are meant as an introduction to Ada. I'm skint now but the books don't > need to be cheap -- but i'd prefer it if they were. > > > Chris Campbell > > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-22 20:11 ` RISC chris.danx 2001-03-22 20:51 ` RISC Marin David Condic @ 2001-03-22 21:02 ` tmoran 2001-03-22 21:18 ` RISC chris.danx 2001-03-22 21:45 ` RISC Britt Snodgrass 2001-03-28 11:37 ` RISC chris.danx 3 siblings, 1 reply; 82+ messages in thread From: tmoran @ 2001-03-22 21:02 UTC (permalink / raw) >Are there any good books on Ada that cover stuff like direct_io, rep clauses >and low level stuff. Most of the books i've got cover ADT/OOP programming >and are meant as an introduction to Ada. I'm skint now but the books don't Have you looked at www.adapower.com for books and tutorials? Personally, I find Cohen's "Ada as a second language" and Barnes' "Programming in Ada 95" to be pretty complete and good follow-ons to an "introduction" book. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-22 20:11 ` RISC chris.danx 2001-03-22 20:51 ` RISC Marin David Condic 2001-03-22 21:02 ` RISC tmoran @ 2001-03-22 21:45 ` Britt Snodgrass 2001-03-22 22:43 ` RISC chris.danx 2001-03-28 11:37 ` RISC chris.danx 3 siblings, 1 reply; 82+ messages in thread From: Britt Snodgrass @ 2001-03-22 21:45 UTC (permalink / raw) Chris, See http://www.research.ibm.com/people/n/ncohen/a3sl.html for info on Cohen's excellent "Ada as a Second Language" for an in-depth Ada 95 reference. Fatbrain.com usually sells it for at least 10% off list price. You can also read about rep specs for free in the Ada 95 Reference Manual at http://www.adapower.com/rm95/arm95_189.html#SEC189 Britt "chris.danx" wrote: > > I've been following the rep clause debate in this thread for sometime. All > of a sudden i had the realisation that i didn't have a clue as to what they > are. So what are rep clauses? > > Are there any good books on Ada that cover stuff like direct_io, rep clauses > and low level stuff. Most of the books i've got cover ADT/OOP programming > and are meant as an introduction to Ada. I'm skint now but the books don't > need to be cheap -- but i'd prefer it if they were. > > Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-22 21:45 ` RISC Britt Snodgrass @ 2001-03-22 22:43 ` chris.danx 0 siblings, 0 replies; 82+ messages in thread From: chris.danx @ 2001-03-22 22:43 UTC (permalink / raw) Thanks for the ref. Still can't afford it until i get third part of student loan in April/May. I looked at the table of contents and i'm not going to be able to do without this book. Thanks again, Chris ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-22 20:11 ` RISC chris.danx ` (2 preceding siblings ...) 2001-03-22 21:45 ` RISC Britt Snodgrass @ 2001-03-28 11:37 ` chris.danx 3 siblings, 0 replies; 82+ messages in thread From: chris.danx @ 2001-03-28 11:37 UTC (permalink / raw) Barnes book arrived this morning, and i had a quick look through it. Looks good, and has more depth than the others i've got. Thanks for the info, Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* RE: RISC
@ 2001-03-16 23:25 Beard, Frank
2001-03-17 11:39 ` RISC chris.danx
0 siblings, 1 reply; 82+ messages in thread
From: Beard, Frank @ 2001-03-16 23:25 UTC (permalink / raw)
To: 'comp.lang.ada@ada.eu.org'
> Does Ada have routines for displaying numbers in Hex or Octal (preferably
> Hex)?
For integers, use the Integer_Io generic in Text_Io:
package Int_Io is new Ada.Text_Io.Integer_Io(integer);
Procedure Put has the following spec:
procedure Put(Item : in Num;
Width : in Field := Default_Width;
Base : in Number_Base := Default_Base);
So,
x : integer := 10;
begin
Int_Io.Put(item => x,
base => 16);
Outputs an A.
For Modular types, use the Modular_Io generic in Text_Io.
type Byte is mod 2**8;
package Mod_Io is new Ada.Text_Io.Modular_Io(Byte);
Procedure Put is defined the same way, as:
procedure Put(Item : in Num;
Width : in Field := Default_Width;
Base : in Number_Base := Default_Base);
So,
x : Byte := 10;
begin
Mod_Io.Put(item => x,
base => 16);
Frank
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-16 23:25 RISC Beard, Frank @ 2001-03-17 11:39 ` chris.danx 0 siblings, 0 replies; 82+ messages in thread From: chris.danx @ 2001-03-17 11:39 UTC (permalink / raw) Thanks very much, Chris Campbell ^ permalink raw reply [flat|nested] 82+ messages in thread
* RE: RISC @ 2001-03-29 3:12 Beard, Frank 2001-03-29 7:28 ` RISC Martin Dowie ` (2 more replies) 0 siblings, 3 replies; 82+ messages in thread From: Beard, Frank @ 2001-03-29 3:12 UTC (permalink / raw) To: 'comp.lang.ada@ada.eu.org' Chris, I haven't been following the thread and someone may have already suggested this, but, along the lines of what Martin was suggesting, can't you do the following: For addition: Register := ... New_Value := Register + delta; if (New_Value < Register) then -- overflow else Register := New_Value; end if; For subtraction: Register := ... New_Value := Register - delta; if (New_Value > Register) then -- underflow else Register := New_Value; end if; For multiplication: Register := ... New_Value := Register * delta; if (New_Value < Register) then -- overflow else Register := New_Value; end if; For division: Register := ... New_Value := Register / delta; if (New_Value > Register) then -- underflow else Register := New_Value; end if; I know this isn't ideal, but it seems like it should work. Another option might be (assuming a 32 bit register): type Bit_Array is array (1..32) of boolean; pragma Pack(Bit_Array); Register_Bits : Bit_Array; for Register_Bits use Register'address; High_Order_Bit_Set := Register_Bits(32); -- After addition and multiplication -- If the high order bit was set and is now clear if High_Order_Bit_Set and then not Register_Bits(32) then -- overflow end if; -- After subtraction and division -- If the high order bit was clear and is now set if not High_Order_Bit_Set and then Register_Bits(32) then -- underflow end if; Or, something like that. It's late and I'm not thinking too clearly. Frank PS. If someone else has already suggested this, and you know of problems, then by all means disregard it. -----Original Message----- From: chris.danx [mailto:chris.danx@ntlworld.com] Sent: Wednesday, March 28, 2001 5:24 PM To: comp.lang.ada@ada.eu.org Subject: Re: RISC mod types have made some parts of the machine simple but are making arithmetic operations a nightmare. I need to support 2s compliment integers (floats will not feature at all) hence mod types. Taking not of X and add 1, then it's negative. no probs! Problem is with sign and overflow on add, sub, mul, div. Each one must cope with signed nums and unsigned ones -- signal a carry or overflow. I think you can just do add/sub and no worries. Problems arise when i detect overflow, i tried thinking this out, and Martin Dowie pointed out a possible solution that might work but only for unsigned nums. I don't know how to go about this signed ones. I really need to know how to detect overflow for multiplication and division. I also need a way to detect it for add and sub. Maybe Ada has an attribute for this or something, e.g. ... type X is mod 256; ... a : x := 128; a := x + x; ... if a'overflow then ... end if; {i doubt it though!} Can anyone help, Thanks, Chris Campbell "Martin Dowie" <martin.dowie@gecm.com> wrote in message news:3ab5d2a4$1@pull.gecm.com... > I had a similar problem recently when I had to mimic unsigned 64 bits with > only > unsigned 32 bits available. > > For addition and subtract it is fairly easy. e.g. > > a = 255, b = 1 > c = a + b > if c < a then overflow as it has wrapped > > similarly for subtraction with > instead of <. > > I only required +/- support, so I'm afraid I have no solutions for * or / > :-( > > The long-hand way for multiplications would be to add e.g. > a = 90, b = 3 > c = 0 > for I in 1 .. b loop > c = c + a > if c < a then overflow as it has wrapped > end loop > > not very efficient... > > Sorry, no ideas spring to mind for division... > > chris.danx <chris.danx@ntlworld.com> wrote in message > news:qrws6.3335$bL.360000@news6-win.server.ntlworld.com... > > Two quickies! I hope! > > > >[snip] > > > > I'm using mod types to simulate registers in the RISC machine. I'm about > to > > implement arithmetic operations but i've thought of a problem. How do i > > detect overflow? > > > > e.g. > > say it was 1 byte reg > > > > 25*158 is too big. > > > > 12+254 is too big also. > > > _______________________________________________ comp.lang.ada mailing list comp.lang.ada@ada.eu.org http://ada.eu.org/mailman/listinfo/comp.lang.ada ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-29 3:12 RISC Beard, Frank @ 2001-03-29 7:28 ` Martin Dowie 2001-03-29 12:38 ` RISC chris.danx 2001-03-29 19:07 ` RISC Chad R. Meiners 2 siblings, 0 replies; 82+ messages in thread From: Martin Dowie @ 2001-03-29 7:28 UTC (permalink / raw) Not sure about that division - wouldn't New_Value simple become 0? Beard, Frank <beardf@spawar.navy.mil> wrote in message news:mailman.985835690.10322.comp.lang.ada@ada.eu.org... > Chris, > [snip] > > For division: > > Register := ... > > New_Value := Register / delta; > > if (New_Value > Register) then > -- underflow > else > Register := New_Value; > end if; ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-29 3:12 RISC Beard, Frank 2001-03-29 7:28 ` RISC Martin Dowie @ 2001-03-29 12:38 ` chris.danx 2001-03-29 19:07 ` RISC Chad R. Meiners 2 siblings, 0 replies; 82+ messages in thread From: chris.danx @ 2001-03-29 12:38 UTC (permalink / raw) Thanks for the suggestions guys, I think these would work, i'm going to try them out. I had thought about this for addition c = a + b if c >= Lim then overflow a + b >= Lim a >= Lim - b -- that'd be overflow; b >= Lim - a -- this too; but i wasn't sure if i'd need to detect both cases. I'll try your suggestions and see what happens. Thanks again, Chris Campbell "Beard, Frank" <beardf@spawar.navy.mil> wrote in message news:mailman.985835690.10322.comp.lang.ada@ada.eu.org... > Chris, > > I haven't been following the thread and someone may have > already suggested this, but, along the lines of what Martin > was suggesting, can't you do the following: > > For addition: > > Register := ... > > New_Value := Register + delta; > > if (New_Value < Register) then > -- overflow > else > Register := New_Value; > end if; > > For subtraction: > > Register := ... > > New_Value := Register - delta; > > if (New_Value > Register) then > -- underflow > else > Register := New_Value; > end if; > > For multiplication: > > Register := ... > > New_Value := Register * delta; > > if (New_Value < Register) then > -- overflow > else > Register := New_Value; > end if; > > For division: > > Register := ... > > New_Value := Register / delta; > > if (New_Value > Register) then > -- underflow > else > Register := New_Value; > end if; > > I know this isn't ideal, but it seems like it should work. > > > Another option might be (assuming a 32 bit register): > > type Bit_Array is array (1..32) of boolean; > pragma Pack(Bit_Array); > > Register_Bits : Bit_Array; > for Register_Bits use Register'address; > > High_Order_Bit_Set := Register_Bits(32); > > -- After addition and multiplication > > -- If the high order bit was set and is now clear > if High_Order_Bit_Set and then not Register_Bits(32) then > -- overflow > end if; > > -- After subtraction and division > > -- If the high order bit was clear and is now set > if not High_Order_Bit_Set and then Register_Bits(32) then > -- underflow > end if; > > Or, something like that. It's late and I'm not thinking too > clearly. > > Frank > > PS. > If someone else has already suggested this, and you know > of problems, then by all means disregard it. > > -----Original Message----- > From: chris.danx [mailto:chris.danx@ntlworld.com] > Sent: Wednesday, March 28, 2001 5:24 PM > To: comp.lang.ada@ada.eu.org > Subject: Re: RISC > > > mod types have made some parts of the machine simple but are making > arithmetic operations a nightmare. > > I need to support 2s compliment integers (floats will not feature at all) > hence mod types. Taking not of X and add 1, then it's negative. no probs! > Problem is with sign and overflow on add, sub, mul, div. > > Each one must cope with signed nums and unsigned ones -- signal a carry or > overflow. I think you can just do add/sub and no worries. Problems arise > when i detect overflow, i tried thinking this out, and Martin Dowie pointed > out a possible solution that might work but only for unsigned nums. I don't > know how to go about this signed ones. > > I really need to know how to detect overflow for multiplication and > division. I also need a way to detect it for add and sub. Maybe Ada has an > attribute for this or something, > > e.g. ... > type X is mod 256; > ... > a : x := 128; > a := x + x; > ... > if a'overflow then > ... > end if; > > {i doubt it though!} > > Can anyone help, > > > Thanks, > Chris Campbell > > "Martin Dowie" <martin.dowie@gecm.com> wrote in message > news:3ab5d2a4$1@pull.gecm.com... > > I had a similar problem recently when I had to mimic unsigned 64 bits with > > only > > unsigned 32 bits available. > > > > For addition and subtract it is fairly easy. e.g. > > > > a = 255, b = 1 > > c = a + b > > if c < a then overflow as it has wrapped > > > > similarly for subtraction with > instead of <. > > > > I only required +/- support, so I'm afraid I have no solutions for * or / > > :-( > > > > The long-hand way for multiplications would be to add e.g. > > a = 90, b = 3 > > c = 0 > > for I in 1 .. b loop > > c = c + a > > if c < a then overflow as it has wrapped > > end loop > > > > not very efficient... > > > > Sorry, no ideas spring to mind for division... > > > > chris.danx <chris.danx@ntlworld.com> wrote in message > > news:qrws6.3335$bL.360000@news6-win.server.ntlworld.com... > > > Two quickies! I hope! > > > > > >[snip] > > > > > > I'm using mod types to simulate registers in the RISC machine. I'm > about > > to > > > implement arithmetic operations but i've thought of a problem. How do i > > > detect overflow? > > > > > > e.g. > > > say it was 1 byte reg > > > > > > 25*158 is too big. > > > > > > 12+254 is too big also. > > > > > > > > > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC 2001-03-29 3:12 RISC Beard, Frank 2001-03-29 7:28 ` RISC Martin Dowie 2001-03-29 12:38 ` RISC chris.danx @ 2001-03-29 19:07 ` Chad R. Meiners 2 siblings, 0 replies; 82+ messages in thread From: Chad R. Meiners @ 2001-03-29 19:07 UTC (permalink / raw) "Beard, Frank" <beardf@spawar.navy.mil> wrote in message news:mailman.985835690.10322.comp.lang.ada@ada.eu.org... > For multiplication: > > Register := ... > > New_Value := Register * delta; > > if (New_Value < Register) then > -- overflow > else > Register := New_Value; > end if; > Let delta = 0 and Register > 0. The result will be an overflow. ^ permalink raw reply [flat|nested] 82+ messages in thread
* RE: RISC @ 2001-03-29 17:52 Beard, Frank 0 siblings, 0 replies; 82+ messages in thread From: Beard, Frank @ 2001-03-29 17:52 UTC (permalink / raw) To: 'comp.lang.ada@ada.eu.org' Probably, I couldn't think of how division could cause it because a remainder of less than one should become zero. But it was late and I figured someone else would check me on it. Thanks Frank -----Original Message----- Not sure about that division - wouldn't New_Value simple become 0? Beard, Frank <beardf@spawar.navy.mil> wrote in message news:mailman.985835690.10322.comp.lang.ada@ada.eu.org... > Chris, > [snip] > > For division: > > Register := ... > > New_Value := Register / delta; > > if (New_Value > Register) then > -- underflow > else > Register := New_Value; > end if; _______________________________________________ comp.lang.ada mailing list comp.lang.ada@ada.eu.org http://ada.eu.org/mailman/listinfo/comp.lang.ada ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: RISC @ 2001-03-30 17:31 Kent Paul Dolan 0 siblings, 0 replies; 82+ messages in thread From: Kent Paul Dolan @ 2001-03-30 17:31 UTC (permalink / raw) References=<9kws6.218$94.1074@www.newsranger.com> Ted Dennison said: => ASN.1 had a lot of this type of stuff. Take the standard => "length octet" for instance (...please!). Bit 8 selects => between "short form" and "long form". In "short form" the => other 7 bits indicate the length of the contents. In "long => form", the other 7 bits indicate how many of the following => bytes are used to determinte the length of the rest of the => contents. (Remember, no problem can't be solved by another => level of indirection...) However, if bit 8 is on and the => rest of the bits are off, then it indicates that we are => using "indefinite form", where two terminator octets at the => end of the contents determine the length. => A week of wrestling with this kind of stuff several years => ago was enough to convince me that there are always going => to be some formats that just cannot be nicely handled at a => high-level with something like a rep clause. Don't put ASN.1 too far in the past. As of Q1 1998, at least, it was alive and well as the data format for SNMP, version 1, and as well as it worked, I can't imagine it being easily replaced. The other way of looking at this issue is probably that if ASN.1 (and BER, _its_ underlying standard) were directly supported as data type families in a compiled language, the questions of worrying how to deal with stream oriented data, or of fighting with representations, would go away. In ASN.1 and BER, those are solved problems, so long as you put each at both ends of the transaction. The folks who designed ASN.1 took on a very hard problem: how do you standardize the representation of dynamically bounded amounts of indefinite precision data, and frankly, strange as the mechanisms seem at first encounter, they are quite elegant once the cultural shock has worn away. Elegant and easy to implement are not synonyms. The horror of knowing that you are going to be doing _everything_ at the bit level has been adequately expressed in another posting in this thread. I ran into identical issues in 1983, tasked with providing a library (in C for the IBM big box of the day, I misremember which) to let other programmers translate UDAF (Uniform Data Access Format, I think) Honeywell 36 bit data to formats suitable for storage on IBM 32/64 bit format media. The answer that worked to translate 20,000 2400' data tapes was to do it all one bit at a time, with certain cheesy optimizations where possible. Cheers! xanthian. -- Kent Paul Dolan <xanthian@well.com> -- Posted from smtp.well.com [208.178.101.27] via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 82+ messages in thread
end of thread, other threads:[~2001-03-30 17:31 UTC | newest] Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-03-14 20:23 RISC chris.danx 2001-03-14 21:57 ` RISC Tucker Taft 2001-03-14 22:36 ` RISC chris.danx 2001-03-14 23:03 ` RISC Fraser Wilson 2001-03-15 1:30 ` RISC Corey Ashford 2001-03-15 9:19 ` RISC chris.danx 2001-03-15 12:37 ` RISC chris.danx 2001-03-15 13:03 ` RISC Tarjei T. Jensen 2001-03-15 18:29 ` RISC Robert A Duff 2001-03-15 14:40 ` RISC Ted Dennison 2001-03-15 14:49 ` RISC Robert A Duff 2001-03-15 17:37 ` RISC Marin David Condic 2001-03-15 18:28 ` RISC Robert A Duff 2001-03-15 19:16 ` RISC Marin David Condic 2001-03-16 8:44 ` RISC Martin Dowie 2001-03-16 14:40 ` RISC Marin David Condic 2001-03-20 10:17 ` RISC Martin Dowie 2001-03-20 14:34 ` RISC Marin David Condic 2001-03-20 15:45 ` RISC Ted Dennison 2001-03-20 16:39 ` RISC Robert A Duff 2001-03-20 18:10 ` RISC Martin Dowie 2001-03-20 18:56 ` RISC Ted Dennison 2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie 2001-03-22 9:34 ` Martin Dowie 2001-03-20 18:09 ` RISC Martin Dowie 2001-03-20 20:00 ` RISC Marin David Condic 2001-03-20 22:30 ` RISC Robert A Duff 2001-03-20 22:48 ` RISC Ted Dennison 2001-03-20 23:10 ` RISC Marin David Condic 2001-03-21 0:18 ` RISC Robert A Duff 2001-03-21 14:31 ` RISC Marin David Condic 2001-03-21 16:47 ` RISC Ted Dennison 2001-03-21 17:36 ` RISC Marin David Condic 2001-03-16 15:09 ` RISC Tucker Taft 2001-03-16 17:10 ` RISC Robert A Duff 2001-03-16 19:02 ` RISC Marin David Condic 2001-03-16 20:58 ` RISC Robert A Duff 2001-03-19 16:17 ` RISC Marin David Condic 2001-03-19 16:45 ` RISC Florian Weimer 2001-03-19 17:14 ` RISC Marin David Condic 2001-03-19 17:33 ` RISC Florian Weimer 2001-03-21 5:57 ` RISC Lao Xiao Hai 2001-03-16 22:19 ` RISC Ted Dennison 2001-03-16 19:13 ` RISC Laurent Guerby 2001-03-16 20:30 ` RISC Robert A Duff 2001-03-16 20:51 ` RISC Ole-Hjalmar Kristensen 2001-03-16 18:33 ` RISC Marin David Condic 2001-03-16 20:45 ` RISC Robert A Duff 2001-03-17 1:13 ` RISC Randy Brukardt 2001-03-19 16:34 ` RISC Marin David Condic 2001-03-19 17:49 ` RISC Robert A Duff 2001-03-16 20:08 ` RISC chris.danx 2001-03-16 20:31 ` RISC Marin David Condic 2001-03-17 21:51 ` RISC Robert A Duff 2001-03-18 6:37 ` RISC Charles Hixson 2001-03-19 15:42 ` RISC Robert A Duff 2001-03-19 17:02 ` RISC Marin David Condic 2001-03-19 17:45 ` RISC Robert A Duff 2001-03-19 18:48 ` RISC Marin David Condic 2001-03-19 16:45 ` RISC Marin David Condic 2001-03-16 22:27 ` RISC chris.danx 2001-03-17 2:49 ` RISC Jeffrey Carter 2001-03-19 9:43 ` RISC Martin Dowie 2001-03-19 11:06 ` RISC chris.danx 2001-03-28 22:24 ` RISC chris.danx 2001-03-29 0:52 ` RISC Corey Ashford 2001-03-29 12:42 ` RISC John English 2001-03-22 20:11 ` RISC chris.danx 2001-03-22 20:51 ` RISC Marin David Condic 2001-03-22 21:02 ` RISC tmoran 2001-03-22 21:18 ` RISC chris.danx 2001-03-22 21:45 ` RISC Britt Snodgrass 2001-03-22 22:43 ` RISC chris.danx 2001-03-28 11:37 ` RISC chris.danx -- strict thread matches above, loose matches on Subject: below -- 2001-03-16 23:25 RISC Beard, Frank 2001-03-17 11:39 ` RISC chris.danx 2001-03-29 3:12 RISC Beard, Frank 2001-03-29 7:28 ` RISC Martin Dowie 2001-03-29 12:38 ` RISC chris.danx 2001-03-29 19:07 ` RISC Chad R. Meiners 2001-03-29 17:52 RISC Beard, Frank 2001-03-30 17:31 RISC Kent Paul Dolan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox