RISC

RISC

[chris.danx]

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!!!

Re: RISC

[Tucker Taft]

"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)

Re: RISC

[chris.danx]

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

Re: RISC

[Fraser Wilson]

"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.

Re: RISC

[Corey Ashford]

"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.

Re: RISC

[chris.danx]

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.

Re: RISC

[chris.danx]

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

Re: RISC

[Tarjei T. Jensen]

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,

Re: RISC

[Ted Dennison]

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

Re: RISC

[Robert A Duff]

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

Re: RISC

[Marin David Condic]

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).

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Marin David Condic]

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
>

Re: RISC

[Martin Dowie]

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.

Re: RISC

[Marin David Condic]

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?
>

Re: RISC

[Tucker Taft]

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)

Re: RISC

[Robert A Duff]

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

Re: RISC

[Marin David Condic]

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>

Re: RISC

[Marin David Condic]

"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/

Re: RISC

[Laurent Guerby]

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>

Re: RISC

[chris.danx]

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

Re: RISC

[Robert A Duff]

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

Re: RISC

[Marin David Condic]

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
>
>

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Ole-Hjalmar Kristensen]

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

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Ted Dennison]

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

Re: RISC

[chris.danx]

[-- 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

RE: RISC

[Beard, Frank]

> 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

Re: RISC

[Randy Brukardt]

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.

Re: RISC

[Jeffrey Carter]

"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

Re: RISC

[chris.danx]

Thanks very much,
Chris Campbell

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Charles Hixson]

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.

Re: RISC

[Martin Dowie]

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.

Re: RISC

[chris.danx]

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.
>
>
>

Re: RISC

[Robert A Duff]

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

Re: RISC

[Marin David Condic]

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.

Re: RISC

[Marin David Condic]

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.
>

Re: RISC

[Florian Weimer]

"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. ;-)

Re: RISC

[Marin David Condic]

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

Re: RISC

[Marin David Condic]

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.
>
>

Re: RISC

[Marin David Condic]

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. ;-)

Re: RISC

[Florian Weimer]

"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.

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Marin David Condic]

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

Re: RISC

[Martin Dowie]

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]

Re: RISC

[Marin David Condic]

"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/

Re: RISC

[Ted Dennison]

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

Re: RISC

[Robert A Duff]

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

Re: RISC

[Martin Dowie]

> 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.

Re: RISC

[Martin Dowie]

> 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?

Re: RISC

[Ted Dennison]

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

Re: RISC

[Marin David Condic]

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 :-(
>
>

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Ted Dennison]

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

Re: RISC

[Marin David Condic]

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

Re: RISC

[Robert A Duff]

"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

Re: RISC

[Lao Xiao Hai]

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

Re: RISC

[Marin David Condic]

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

Re: RISC

[Ted Dennison]

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

Re: RISC

[Marin David Condic]

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

Re: RISC

[chris.danx]

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

Re: RISC

[Marin David Condic]

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
>
>

Re: RISC

[tmoran]

>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.

Re: RISC

[chris.danx]

I decided to go with Barnes, it's cheaper!!!

Chris Campbell

Re: RISC

[Britt Snodgrass]

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

Re: RISC

[chris.danx]

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

Re: RISC

[chris.danx]

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

Re: RISC

[chris.danx]

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.
>
>
>

Re: RISC

[Corey Ashford]

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.
> >
> >
> >
>

RE: RISC

[Beard, Frank]

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

Re: RISC

[Martin Dowie]

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;

Re: RISC

[chris.danx]

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
>

Re: RISC

[John English]

"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
-----------------------------------------------------------------

RE: RISC

[Beard, Frank]

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

Re: RISC

[Chad R. Meiners]

"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.

Re: RISC

[Kent Paul Dolan]

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