* RE: RISC - largish (code listed)
@ 2001-03-22 18:31 Beard, Frank
2001-03-23 8:36 ` Martin Dowie
0 siblings, 1 reply; 5+ messages in thread
From: Beard, Frank @ 2001-03-22 18:31 UTC (permalink / raw)
To: 'comp.lang.ada@ada.eu.org'
Any particular reason you don't use "System.Address_To_Access_Conversions"?
Frank
-----Original Message-----
From: Martin Dowie [mailto:martin.dowie@baesystems.com]
Sent: Thursday, March 22, 2001 4:16 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: RISC - largish (code listed)
Something like this? Seems _well_ dangerous but also seems to produce very
little code...
Ted Dennison <dennison@telepath.com> wrote in message
news:LWKt6.1865$94.2578@www.newsranger.com...
> That's why if the object is largish I typically use unchecked_conversion
on
> pointers to the object instead. Depending on the smarts of the compiler,
that
> might not generate any code at all.
>
> I don't like "for use at" overlays. For one thing, initializations get
(re)done
> when the overlay happens, which could wipe out important stuff. For
another, the
> aliasing is (generally) given a much wider scope than is achievable with
> unchecked conversion.
-- Unchecked_Accessors Spec:
with System;
generic
type Object1 (<>) is limited private;
type Object1_Pointer is access all Object1;
with function To_Object1_Pointer (Address : System.Address) return
Object1_Pointer;
with function To_Object1_Address (Obj1_Ptr : Object1_Pointer) return
System.Address;
type Object2 (<>) is limited private;
type Object2_Pointer is access all Object2;
with function To_Object2_Pointer (Address : System.Address) return
Object2_Pointer;
with function To_Object2_Address (Obj2_Ptr : Object2_Pointer) return
System.Address;
package Unchecked_Accessors is
function To_Object1_Pointer (Obj2_Ptr : Object2_Pointer) return
Object1_Pointer;
function To_Object2_Pointer (Obj1_Ptr : Object1_Pointer) return
Object2_Pointer;
pragma Inline (To_Object1_Pointer);
pragma Inline (To_Object2_Pointer);
end Unchecked_Accessors;
-- Unchecked_Accessors Body:
package body Unchecked_Accessors is
function To_Object1_Pointer (Obj2_Ptr : Object2_Pointer) return
Object1_Pointer is
begin
return To_Object1_Pointer (Address => To_Object2_Address (Obj2_Ptr =>
Obj2_Ptr));
end To_Object1_Pointer;
function To_Object2_Pointer (Obj1_Ptr : Object1_Pointer) return
Object2_Pointer is
begin
return To_Object2_Pointer (Address => To_Object1_Address (Obj1_Ptr =>
Obj1_Ptr));
end To_Object2_Pointer;
end Unchecked_Accessors;
-- Test Harness:
with Ada.Text_IO; use Ada.Text_IO;
with System.Address_To_Access_Conversions;
with Unchecked_Accessors;
procedure Test_Unchecked_Access_Conversion is
type A_Record (Variant : Boolean := False) is record
Item1 : Integer;
case Variant is
when False =>
Item2 : Float;
when True =>
Item3 : Boolean;
Item4 : String (1 .. 10);
end case;
end record;
package Record_Conversions is
new System.Address_To_Access_Conversions (Object => A_Record);
My_Object : aliased A_Record := (Variant => True,
Item1 => Integer'Last,
Item3 => True,
Item4 => "0123456789");
type A_String is new String (1 .. My_Object'Size / 8);
package String_Conversions is
new System.Address_To_Access_Conversions (Object => A_String);
package My_Conversions is
new Unchecked_Accessors (Object1 => A_Record,
Object1_Pointer =>
Record_Conversions.Object_Pointer,
To_Object1_Pointer =>
Record_Conversions.To_Pointer,
To_Object1_Address =>
Record_Conversions.To_Address,
Object2 => A_String,
Object2_Pointer =>
String_Conversions.Object_Pointer,
To_Object2_Pointer =>
String_Conversions.To_Pointer,
To_Object2_Address =>
String_Conversions.To_Address);
My_String_Access : String_Conversions.Object_Pointer;
begin
My_String_Access := My_Conversions.To_Object2_Pointer (Obj1_Ptr =>
My_Object'Access);
Put_Line (String (My_String_Access.all));
end Test_Unchecked_Access_Conversion;
Assempler for Unchecked_Accessors:
.file "unchecked_accessors.adb"
gcc2_compiled.:
___gnu_compiled_ada:
.stabs "W:/Personal/Ada/Utilities/",100,0,0,Ltext0
.stabs "w:/personal/ada/utilit~1/unchecked_accessors.adb",100,0,0,Ltext0
.text
Ltext0:
.stabs "long int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
.stabs "unsigned char:t(0,2)=@s8;r(0,2);0;255;",128,0,0,0
.stabs "boolean___XDLU_0__1:t(0,3)=@s8;efalse:0,true:1,;",128,0,1,0
.stabs "character:t(0,4)=@s8;r(0,4);0;255;",128,0,1,0
.stabs "natural___XDLU_0__2147483647:t(0,5)=r(0,1);0;2147483647;",128,0,1,0
.stabs "access_character:t(0,6)=*(0,4)",128,0,1,0
.stabs "integer:t(0,7)=r(0,1);-2147483648;2147483647;",128,0,1,0
.stabs
"exception:T(0,8)=s20not_handled_by_others:(0,3),0,8;c1:(0,4),8,8;c2:(0,4),1
6,8;c3:(0,4),24,8;name_length:(0,5),32,32;full_name:(0,6),64,32;htable_ptr:(
0,6),96,32;import_code:(0,7),128,32;;",128,0,0,0
.stabs "exception:t(0,8)",128,0,1,0
.stabs "long_long_float:t(0,9)=r(0,1);12;0;",128,0,1,0
.globl _unchecked_accessors_E
.data
.stabs "unchecked_accessors_E:G(0,3)",32,0,13,0
_unchecked_accessors_E:
.byte 0
.text
.align 4
.stabs
"unchecked_accessors___elabb:F(0,10)=(0,10)",36,0,1,_unchecked_accessors___e
labb
.globl _unchecked_accessors___elabb
_unchecked_accessors___elabb:
.stabn 68,0,1,LM1-_unchecked_accessors___elabb
LM1:
pushl %ebp
movl %esp,%ebp
.stabn 68,0,1,LM2-_unchecked_accessors___elabb
LM2:
movb $1,_unchecked_accessors_E
.stabn 68,0,1,LM3-_unchecked_accessors___elabb
LM3:
L1:
movl %ebp,%esp
popl %ebp
ret
Lscope0:
.stabs "",36,0,0,Lscope0-_unchecked_accessors___elabb
.text
.stabs "",100,0,0,Letext
Letext:
Test Results:
? ??0123456789
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC - largish (code listed)
2001-03-22 18:31 RISC - largish (code listed) Beard, Frank
@ 2001-03-23 8:36 ` Martin Dowie
2001-03-23 12:21 ` David C. Hoos, Sr.
0 siblings, 1 reply; 5+ messages in thread
From: Martin Dowie @ 2001-03-23 8:36 UTC (permalink / raw)
Beard, Frank <beardf@spawar.navy.mil> wrote in message
news:mailman.985286058.25350.comp.lang.ada@ada.eu.org...
> Any particular reason you don't use
"System.Address_To_Access_Conversions"?
we do - in the body. This package converts one access type to another access
type by converting to system.address on route. So you can do dangerous
things
in a type safe manner.
If there is a simpler way of doing this (type safely) then please let me
know! :-)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC - largish (code listed)
2001-03-23 8:36 ` Martin Dowie
@ 2001-03-23 12:21 ` David C. Hoos, Sr.
0 siblings, 0 replies; 5+ messages in thread
From: David C. Hoos, Sr. @ 2001-03-23 12:21 UTC (permalink / raw)
"Martin Dowie" <martin.dowie@baesystems.com> wrote in message
news:3abb0937$1@pull.gecm.com...
> Beard, Frank <beardf@spawar.navy.mil> wrote in message
> news:mailman.985286058.25350.comp.lang.ada@ada.eu.org...
> > Any particular reason you don't use
> "System.Address_To_Access_Conversions"?
>
> we do - in the body. This package converts one access type to another
access
> type by converting to system.address on route. So you can do dangerous
> things
> in a type safe manner.
>
> If there is a simpler way of doing this (type safely) then please let me
> know! :-)
As a matter of good style (regardless of simplicity) it's always a good idea
to
hide implementation details from the specification, even when the
implementation is only an instantiation of a language-defined generic unit.
This allows refinement of the implementation without changing the
specification and thereby forcing recompilation of all of the client units.
^ permalink raw reply [flat|nested] 5+ messages in thread
* RISC
@ 2001-03-14 20:23 chris.danx
2001-03-15 12:37 ` RISC chris.danx
0 siblings, 1 reply; 5+ messages in thread
From: chris.danx @ 2001-03-14 20:23 UTC (permalink / raw)
Hi,
I'm simulating a RISC machine in Ada. Eventually the instructions will
be mapped to native architecture (x86, m68xxx, SPARC, etc), but for now i
want to simulate a machine, to limit the possibility of doing something
nasty to anyone's machine.
I've decided to provide byte, word and long word modes for most
instructions. The problem comes when clearing or setting byte or word
portions of a register (the machine is loosely based on M68000). The
register is long word (32bit) and i want to set the lower 16bits or 8bits.
I've managed to get this to work, problem is it's not very efficient.
The register is of type 'mod', so i divided by 2**8 or 2**16 then multiplied
by it. I know multiplication and division are costly and really i'm looking
for something more efficient. If this were Pascal i'd use 'shift
left/right' which is quite fast. What should i do to speed it up? Does Ada
have a shift L/R operation? Is there another way to do it?
I have another problem with memory. I thought about allocating one big
block of memory (as an array) and accessing it by index. The problem? I do
plan to dynamically allocate the memory, but i'll still be limited by the
amount of memory allocable in a single array. I've thought of a few ways of
doing this but can't seem to avoid problems! Anyone know of a solution? I
don't like using C, but i 'd run in to a similar problem binding with C
anyway.
Thanks,
Chris Campbell
p.s. This isn't a homework assignment!!!
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-14 20:23 RISC chris.danx
@ 2001-03-15 12:37 ` chris.danx
2001-03-15 14:40 ` RISC Ted Dennison
0 siblings, 1 reply; 5+ messages in thread
From: chris.danx @ 2001-03-15 12:37 UTC (permalink / raw)
I'm curious about 'mod' types. If i define a type 'byte' like so
* type byte is mod 256;
will it occupy one byte of memory.
similarly if i define
* type word is mod 65536
will it occupy two bytes.
This is important for IO and for memory in the simulation. Is it compiler
dependant? I'm using GNAT 3.13p just in case this is so.
As i was writing i suddenly realised i got a problem with little/big
endian-ness. I'm writing files on an Athlon(so it's x86) which is little(i
think). If i port to a M68000 say, which is big endian (again i'm unsure),
what should i do to convert the 'bytecode' file. I dunno what to do with
this. I do plan to port to other platforms in the future so this is
important. Is it true that all networks use big endian? Anyway this is for
the future, just thought i'd ask in case i need to plan ahead for this.
Chris Campbell
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-15 12:37 ` RISC chris.danx
@ 2001-03-15 14:40 ` Ted Dennison
2001-03-15 14:49 ` RISC Robert A Duff
0 siblings, 1 reply; 5+ messages in thread
From: Ted Dennison @ 2001-03-15 14:40 UTC (permalink / raw)
In article <NH2s6.4048$y47.865896@news2-win.server.ntlworld.com>, chris.danx
says...
>
>I'm curious about 'mod' types. If i define a type 'byte' like so
>
>* type byte is mod 256;
>
>will it occupy one byte of memory.
It will if you also do the following:
for byte'size use 8;
If you don't do that, its completely up to the compiler.
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
home email - mailto:dennison@telepath.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-15 14:40 ` RISC Ted Dennison
@ 2001-03-15 14:49 ` Robert A Duff
2001-03-15 17:37 ` RISC Marin David Condic
0 siblings, 1 reply; 5+ messages in thread
From: Robert A Duff @ 2001-03-15 14:49 UTC (permalink / raw)
Ted Dennison<dennison@telepath.com> writes:
> In article <NH2s6.4048$y47.865896@news2-win.server.ntlworld.com>, chris.danx
> says...
> >
> >I'm curious about 'mod' types. If i define a type 'byte' like so
> >
> >* type byte is mod 256;
> >
> >will it occupy one byte of memory.
>
> It will if you also do the following:
>
> for byte'size use 8;
>
> If you don't do that, its completely up to the compiler.
That's not quite right. 'Size clauses on *subtypes* don't necessarily
do what you most people think (unfortunately).
Byte'Size = 8 by default, and whether you say the above or not, it's a
*minimum* size -- the compiler is free to allocate 32 bits for an object
of type Byte. In fact, for a parameter, the object will most likely end
up in a register.
If you want to control the size of an object, put a 'Size clause on the
object. Or if it's a record or array component, use a record_rep_clause
or a Component_Size clause (resp).
- Bob
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-15 14:49 ` RISC Robert A Duff
@ 2001-03-15 17:37 ` Marin David Condic
2001-03-15 18:28 ` RISC Robert A Duff
0 siblings, 1 reply; 5+ messages in thread
From: Marin David Condic @ 2001-03-15 17:37 UTC (permalink / raw)
To make matters worse, a compiler is free in general to refuse to accept
*any* representation clause - You Can't Always Get What You Want....
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccpufjaxz5.fsf@world.std.com...
> That's not quite right. 'Size clauses on *subtypes* don't necessarily
> do what you most people think (unfortunately).
>
> Byte'Size = 8 by default, and whether you say the above or not, it's a
> *minimum* size -- the compiler is free to allocate 32 bits for an object
> of type Byte. In fact, for a parameter, the object will most likely end
> up in a register.
>
> If you want to control the size of an object, put a 'Size clause on the
> object. Or if it's a record or array component, use a record_rep_clause
> or a Component_Size clause (resp).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-15 17:37 ` RISC Marin David Condic
@ 2001-03-15 18:28 ` Robert A Duff
2001-03-15 19:16 ` RISC Marin David Condic
0 siblings, 1 reply; 5+ messages in thread
From: Robert A Duff @ 2001-03-15 18:28 UTC (permalink / raw)
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> To make matters worse, a compiler is free in general to refuse to accept
> *any* representation clause - You Can't Always Get What You Want....
True, but don't all compilers these days support the SP annex, which
requires a fair amount of support for rep clauses? Anyway, in practise,
"for Byte_Object'Size use 8;" will probably be accepted by every
compiler for every 8-bit-byte-addressable machine, and will work as you
expect. It's just the 'Size on subtypes that has "questionable"
semantics.
- Bob
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-15 18:28 ` RISC Robert A Duff
@ 2001-03-15 19:16 ` Marin David Condic
2001-03-16 8:44 ` RISC Martin Dowie
0 siblings, 1 reply; 5+ messages in thread
From: Marin David Condic @ 2001-03-15 19:16 UTC (permalink / raw)
Oh sure. Most garden variety representation clauses get listened to and
obeyed. At least in my experience. I just like to complain about the
inability to coerce behavior out of compilers sometimes. I know I've come up
with perfectly reasonable and legal representation specifications from time
to time and had them rejected by compilers because a) they didn't understand
what I wanted or b) they *did* understand and refused to do it because
obviously they knew better than I did what it is I *really* wanted, if only
I was as smart and omnipotent as the compiler.
That's when you have to get creative in the stories you tell to the
compiler! :-)
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccbsr23n0q.fsf@world.std.com...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
> > To make matters worse, a compiler is free in general to refuse to accept
> > *any* representation clause - You Can't Always Get What You Want....
>
> True, but don't all compilers these days support the SP annex, which
> requires a fair amount of support for rep clauses? Anyway, in practise,
> "for Byte_Object'Size use 8;" will probably be accepted by every
> compiler for every 8-bit-byte-addressable machine, and will work as you
> expect. It's just the 'Size on subtypes that has "questionable"
> semantics.
>
> - Bob
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-15 19:16 ` RISC Marin David Condic
@ 2001-03-16 8:44 ` Martin Dowie
2001-03-16 14:40 ` RISC Marin David Condic
0 siblings, 1 reply; 5+ messages in thread
From: Martin Dowie @ 2001-03-16 8:44 UTC (permalink / raw)
I gave up on record rep clauses a while back after similar frustrations. Am
I
alone in this? These days, for interface level stuff I work with byte arrays
and
do all the conversions explicitly myself (loads of modular arithmatic, which
I'd
have to admit finding quite fun getting what I want sometimes :-)
Has anyone been down this path before and stopped any pitfalls I'm not
aware of?
Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message
news:98r4g1$7r1$1@nh.pace.co.uk...
> Oh sure. Most garden variety representation clauses get listened to and
> obeyed. At least in my experience. I just like to complain about the
> inability to coerce behavior out of compilers sometimes. I know I've come
up
> with perfectly reasonable and legal representation specifications from
time
> to time and had them rejected by compilers because a) they didn't
understand
> what I wanted or b) they *did* understand and refused to do it because
> obviously they knew better than I did what it is I *really* wanted, if
only
> I was as smart and omnipotent as the compiler.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-16 8:44 ` RISC Martin Dowie
@ 2001-03-16 14:40 ` Marin David Condic
2001-03-20 10:17 ` RISC Martin Dowie
0 siblings, 1 reply; 5+ messages in thread
From: Marin David Condic @ 2001-03-16 14:40 UTC (permalink / raw)
No, you are not alone. There have been a number of times that I and others
have raised problems in this forum relating to representation clauses. I
have had particular troubles with representation clauses on tagged records
and private records. I know others have had similar experiences. Inevitably,
there are work-arounds that will let you get the job done, but they are
typically inefficient or inelegant or, more commonly, both.
Resorting to some version of byte arrays & unchecked conversions or overlays
is one way of dealing with it. However (while it is typically reasonably
efficient) I find those solutions to be inelegant in that - if for no other
reason - the compiler ought to know where record fields lie and ought to be
able to keep track of that stuff better than I can - so why shouldn't it get
the job of knowing where to divide up the bytes and bits? (I want to fight
the problem, not the compiler or the language!) If you hide the movement of
bytes-to-fields/fields-to-bytes down at some low level, at least you hide
the information from the rest of the system and isolate your problems. It
just frustrates me because I can see much nicer, much more elegant ways of
doing this sort of thing and it is only slightly out of reach.....
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Martin Dowie" <martin.dowie@gecm.com> wrote in message
news:3ab1d090$1@pull.gecm.com...
> I gave up on record rep clauses a while back after similar frustrations.
Am
> I
> alone in this? These days, for interface level stuff I work with byte
arrays
> and
> do all the conversions explicitly myself (loads of modular arithmatic,
which
> I'd
> have to admit finding quite fun getting what I want sometimes :-)
>
> Has anyone been down this path before and stopped any pitfalls I'm not
> aware of?
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-16 14:40 ` RISC Marin David Condic
@ 2001-03-20 10:17 ` Martin Dowie
2001-03-20 14:34 ` RISC Marin David Condic
0 siblings, 1 reply; 5+ messages in thread
From: Martin Dowie @ 2001-03-20 10:17 UTC (permalink / raw)
I have to confess to using checked conversion - I hadn't concidered
overlays.
Thinking about it I'm not sure I could as we try and avoid having _any_
representation clauses on any of the type that we use within the
application.
If I were to use an overlay, is it possible to use a 'Valid check on the
resulting
object and verify it that way?
Am I right in thinking that overlays are now 'guarenteed' to work as we
lay-people
expect? I know in '83 they were 'a bad thing' although they worked in every
case I ever saw them used.
Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote in message
news:98t8la$rc$1@nh.pace.co.uk...
> No, you are not alone. There have been a number of times that I and others
> have raised problems in this forum relating to representation clauses. I
> have had particular troubles with representation clauses on tagged records
> and private records. I know others have had similar experiences.
Inevitably,
> there are work-arounds that will let you get the job done, but they are
> typically inefficient or inelegant or, more commonly, both.
>
> Resorting to some version of byte arrays & unchecked conversions or
overlays
[snip]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-20 10:17 ` RISC Martin Dowie
@ 2001-03-20 14:34 ` Marin David Condic
2001-03-20 15:45 ` RISC Ted Dennison
0 siblings, 1 reply; 5+ messages in thread
From: Marin David Condic @ 2001-03-20 14:34 UTC (permalink / raw)
"Martin Dowie" <martin.dowie@baesystems.com> wrote in message
news:3ab72c8f$1@pull.gecm.com...
> I have to confess to using checked conversion - I hadn't concidered
> overlays.
>
Do you mean unchecked conversion? That works, but it forces you to move the
data twice just to satisfy language rules & may be too inefficient for some
apps. Its not A Bad Thing in my estimation, but I'd rather not have to.
> Thinking about it I'm not sure I could as we try and avoid having _any_
> representation clauses on any of the type that we use within the
> application.
>
Well, that's fine for everything used internal to the system. The moment
data enters/leaves the system from/to some other source, you *really* want
to guarantee the representation is what is expected. How would you do this
without representation clauses?
> If I were to use an overlay, is it possible to use a 'Valid check on the
> resulting
> object and verify it that way?
>
You'd have to check with a language lawyer. My impression is that this is
what the attribute is for. Go ahead and declare a stream of bytes for the
I/O part to work. Once you get the data, you reference an overlaid record to
pull the data apart. I think the 'Valid attribute should force a check of
the data "assigned" to the record. (Probably works with Unchecked_Conversion
as well...) Of course, you just do all this stuff backwards to handle
output.
> Am I right in thinking that overlays are now 'guarenteed' to work as we
> lay-people
> expect? I know in '83 they were 'a bad thing' although they worked in
every
> case I ever saw them used.
I don't think overlays were ever not "guaranteed to work" in Ada83 - at
least no more or less so than in Ada95. (You may have cases where the
compiler or linker pukes on you. I've had this happen attempting to overlay
things from different contexts.) They were/are considered to be "A Bad
Thing" because of the inherent lack of safety involved. (Much like the use
of gotos is frowned upon, but they are still supported.) It is recognized
that overlays can provide an elegant and effective solution to a number of
problems (such as this one!) if they are used carefully and judiciously. The
language attempts to discourage their use because programmers will, like
most normal people, abuse the privilege if left unrestrained.
I think the ARM probably says something about programs relying on overlays
being "erroneous" or some other carefully defined term that basically means
"it may work but all bets are off from a language lawyer's perspective."
This is probably because there is no good universal way of defining behavior
across all hardware and compiler implementations.
So go ahead and use overlays, but realize you're operating without a net.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC
2001-03-20 14:34 ` RISC Marin David Condic
@ 2001-03-20 15:45 ` Ted Dennison
2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie
0 siblings, 1 reply; 5+ messages in thread
From: Ted Dennison @ 2001-03-20 15:45 UTC (permalink / raw)
In article <997pq4$i35$1@nh.pace.co.uk>, Marin David Condic says...
>
>"Martin Dowie" <martin.dowie@baesystems.com> wrote in message
>news:3ab72c8f$1@pull.gecm.com...
>> I have to confess to using checked conversion - I hadn't concidered
>> overlays.
>>
>Do you mean unchecked conversion? That works, but it forces you to move the
>data twice just to satisfy language rules & may be too inefficient for some
>apps. Its not A Bad Thing in my estimation, but I'd rather not have to.
That's why if the object is largish I typically use unchecked_conversion on
pointers to the object instead. Depending on the smarts of the compiler, that
might not generate any code at all.
I don't like "for use at" overlays. For one thing, initializations get (re)done
when the overlay happens, which could wipe out important stuff. For another, the
aliasing is (generally) given a much wider scope than is achievable with
unchecked conversion.
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
home email - mailto:dennison@telepath.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC - largish (code listed)
2001-03-20 15:45 ` RISC Ted Dennison
@ 2001-03-22 9:16 ` Martin Dowie
2001-03-22 9:34 ` Martin Dowie
0 siblings, 1 reply; 5+ messages in thread
From: Martin Dowie @ 2001-03-22 9:16 UTC (permalink / raw)
Something like this? Seems _well_ dangerous but also seems to produce very
little code...
Ted Dennison <dennison@telepath.com> wrote in message
news:LWKt6.1865$94.2578@www.newsranger.com...
> That's why if the object is largish I typically use unchecked_conversion
on
> pointers to the object instead. Depending on the smarts of the compiler,
that
> might not generate any code at all.
>
> I don't like "for use at" overlays. For one thing, initializations get
(re)done
> when the overlay happens, which could wipe out important stuff. For
another, the
> aliasing is (generally) given a much wider scope than is achievable with
> unchecked conversion.
-- Unchecked_Accessors Spec:
with System;
generic
type Object1 (<>) is limited private;
type Object1_Pointer is access all Object1;
with function To_Object1_Pointer (Address : System.Address) return
Object1_Pointer;
with function To_Object1_Address (Obj1_Ptr : Object1_Pointer) return
System.Address;
type Object2 (<>) is limited private;
type Object2_Pointer is access all Object2;
with function To_Object2_Pointer (Address : System.Address) return
Object2_Pointer;
with function To_Object2_Address (Obj2_Ptr : Object2_Pointer) return
System.Address;
package Unchecked_Accessors is
function To_Object1_Pointer (Obj2_Ptr : Object2_Pointer) return
Object1_Pointer;
function To_Object2_Pointer (Obj1_Ptr : Object1_Pointer) return
Object2_Pointer;
pragma Inline (To_Object1_Pointer);
pragma Inline (To_Object2_Pointer);
end Unchecked_Accessors;
-- Unchecked_Accessors Body:
package body Unchecked_Accessors is
function To_Object1_Pointer (Obj2_Ptr : Object2_Pointer) return
Object1_Pointer is
begin
return To_Object1_Pointer (Address => To_Object2_Address (Obj2_Ptr =>
Obj2_Ptr));
end To_Object1_Pointer;
function To_Object2_Pointer (Obj1_Ptr : Object1_Pointer) return
Object2_Pointer is
begin
return To_Object2_Pointer (Address => To_Object1_Address (Obj1_Ptr =>
Obj1_Ptr));
end To_Object2_Pointer;
end Unchecked_Accessors;
-- Test Harness:
with Ada.Text_IO; use Ada.Text_IO;
with System.Address_To_Access_Conversions;
with Unchecked_Accessors;
procedure Test_Unchecked_Access_Conversion is
type A_Record (Variant : Boolean := False) is record
Item1 : Integer;
case Variant is
when False =>
Item2 : Float;
when True =>
Item3 : Boolean;
Item4 : String (1 .. 10);
end case;
end record;
package Record_Conversions is
new System.Address_To_Access_Conversions (Object => A_Record);
My_Object : aliased A_Record := (Variant => True,
Item1 => Integer'Last,
Item3 => True,
Item4 => "0123456789");
type A_String is new String (1 .. My_Object'Size / 8);
package String_Conversions is
new System.Address_To_Access_Conversions (Object => A_String);
package My_Conversions is
new Unchecked_Accessors (Object1 => A_Record,
Object1_Pointer =>
Record_Conversions.Object_Pointer,
To_Object1_Pointer =>
Record_Conversions.To_Pointer,
To_Object1_Address =>
Record_Conversions.To_Address,
Object2 => A_String,
Object2_Pointer =>
String_Conversions.Object_Pointer,
To_Object2_Pointer =>
String_Conversions.To_Pointer,
To_Object2_Address =>
String_Conversions.To_Address);
My_String_Access : String_Conversions.Object_Pointer;
begin
My_String_Access := My_Conversions.To_Object2_Pointer (Obj1_Ptr =>
My_Object'Access);
Put_Line (String (My_String_Access.all));
end Test_Unchecked_Access_Conversion;
Assempler for Unchecked_Accessors:
.file "unchecked_accessors.adb"
gcc2_compiled.:
___gnu_compiled_ada:
.stabs "W:/Personal/Ada/Utilities/",100,0,0,Ltext0
.stabs "w:/personal/ada/utilit~1/unchecked_accessors.adb",100,0,0,Ltext0
.text
Ltext0:
.stabs "long int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
.stabs "unsigned char:t(0,2)=@s8;r(0,2);0;255;",128,0,0,0
.stabs "boolean___XDLU_0__1:t(0,3)=@s8;efalse:0,true:1,;",128,0,1,0
.stabs "character:t(0,4)=@s8;r(0,4);0;255;",128,0,1,0
.stabs "natural___XDLU_0__2147483647:t(0,5)=r(0,1);0;2147483647;",128,0,1,0
.stabs "access_character:t(0,6)=*(0,4)",128,0,1,0
.stabs "integer:t(0,7)=r(0,1);-2147483648;2147483647;",128,0,1,0
.stabs
"exception:T(0,8)=s20not_handled_by_others:(0,3),0,8;c1:(0,4),8,8;c2:(0,4),1
6,8;c3:(0,4),24,8;name_length:(0,5),32,32;full_name:(0,6),64,32;htable_ptr:(
0,6),96,32;import_code:(0,7),128,32;;",128,0,0,0
.stabs "exception:t(0,8)",128,0,1,0
.stabs "long_long_float:t(0,9)=r(0,1);12;0;",128,0,1,0
.globl _unchecked_accessors_E
.data
.stabs "unchecked_accessors_E:G(0,3)",32,0,13,0
_unchecked_accessors_E:
.byte 0
.text
.align 4
.stabs
"unchecked_accessors___elabb:F(0,10)=(0,10)",36,0,1,_unchecked_accessors___e
labb
.globl _unchecked_accessors___elabb
_unchecked_accessors___elabb:
.stabn 68,0,1,LM1-_unchecked_accessors___elabb
LM1:
pushl %ebp
movl %esp,%ebp
.stabn 68,0,1,LM2-_unchecked_accessors___elabb
LM2:
movb $1,_unchecked_accessors_E
.stabn 68,0,1,LM3-_unchecked_accessors___elabb
LM3:
L1:
movl %ebp,%esp
popl %ebp
ret
Lscope0:
.stabs "",36,0,0,Lscope0-_unchecked_accessors___elabb
.text
.stabs "",100,0,0,Letext
Letext:
Test Results:
? ??0123456789
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RISC - largish (code listed)
2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie
@ 2001-03-22 9:34 ` Martin Dowie
0 siblings, 0 replies; 5+ messages in thread
From: Martin Dowie @ 2001-03-22 9:34 UTC (permalink / raw)
oops forgot the assembler for the instantiation.. still not a lot extra for
these 2 routines.
Martin Dowie <martin.dowie@baesystems.com> wrote in message
news:3ab9c0e9$1@pull.gecm.com...
> Something like this? Seems _well_ dangerous but also seems to produce very
> little code...
>
> Ted Dennison <dennison@telepath.com> wrote in message
> news:LWKt6.1865$94.2578@www.newsranger.com...
> > That's why if the object is largish I typically use unchecked_conversion
> on
> > pointers to the object instead. Depending on the smarts of the compiler,
> that
> > might not generate any code at all.
> >
> > I don't like "for use at" overlays. For one thing, initializations get
> (re)done
> > when the overlay happens, which could wipe out important stuff. For
> another, the
> > aliasing is (generally) given a much wider scope than is achievable with
> > unchecked conversion.
Ltext2:
.stabn
68,0,3,LM19-_test_unchecked_access_conversion__my_conversions__to_object1_po
inter$2.8
LM19:
pushl %ebp
movl %esp,%ebp
subl $4,%esp
movl %ecx,-4(%ebp)
.stabn
68,0,5,LM20-_test_unchecked_access_conversion__my_conversions__to_object1_po
inter$2.8
LM20:
movl 8(%ebp),%eax
pushl %eax
movl -4(%ebp),%ecx
call _test_unchecked_access_conversion__string_conversions__to_address.7
addl $4,%esp
movl %eax,%eax
pushl %eax
movl -4(%ebp),%ecx
call _test_unchecked_access_conversion__record_conversions__to_pointer.4
addl $4,%esp
movl %eax,%edx
movl %edx,%eax
jmp L10
.align 2,0x90
.stabn
68,0,5,LM21-_test_unchecked_access_conversion__my_conversions__to_object1_po
inter$2.8
LM21:
L10:
movl %ebp,%esp
popl %ebp
ret
Lscope4:
.stabs
"",36,0,0,Lscope4-_test_unchecked_access_conversion__my_conversions__to_obje
ct1_pointer$2.8
.align 4
.stabs
"test_unchecked_access_conversion__my_conversions__to_object2_pointer$2:f(0,
46),test_unchecked_access_conversion__my_conversions__to_object2_pointer$2,t
est_unchecked_access_conversion",36,0,8,_test_unchecked_access_conversion__m
y_conversions__to_object2_pointer$2.9
.stabs "obj1_ptr:p(0,29)",160,0,15,8
_test_unchecked_access_conversion__my_conversions__to_object2_pointer$2.9:
.stabn
68,0,8,LM22-_test_unchecked_access_conversion__my_conversions__to_object2_po
inter$2.9
LM22:
pushl %ebp
movl %esp,%ebp
subl $4,%esp
movl %ecx,-4(%ebp)
.stabn
68,0,10,LM23-_test_unchecked_access_conversion__my_conversions__to_object2_p
ointer$2.9
LM23:
movl 8(%ebp),%eax
pushl %eax
movl -4(%ebp),%ecx
call _test_unchecked_access_conversion__record_conversions__to_address.5
addl $4,%esp
movl %eax,%eax
pushl %eax
movl -4(%ebp),%ecx
call _test_unchecked_access_conversion__string_conversions__to_pointer.6
addl $4,%esp
movl %eax,%edx
movl %edx,%eax
jmp L11
.align 2,0x90
.stabn
68,0,10,LM24-_test_unchecked_access_conversion__my_conversions__to_object2_p
ointer$2.9
LM24:
L11:
movl %ebp,%esp
popl %ebp
ret
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-03-23 12:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-22 18:31 RISC - largish (code listed) Beard, Frank
2001-03-23 8:36 ` Martin Dowie
2001-03-23 12:21 ` David C. Hoos, Sr.
-- strict thread matches above, loose matches on Subject: below --
2001-03-14 20:23 RISC chris.danx
2001-03-15 12:37 ` RISC chris.danx
2001-03-15 14:40 ` RISC Ted Dennison
2001-03-15 14:49 ` RISC Robert A Duff
2001-03-15 17:37 ` RISC Marin David Condic
2001-03-15 18:28 ` RISC Robert A Duff
2001-03-15 19:16 ` RISC Marin David Condic
2001-03-16 8:44 ` RISC Martin Dowie
2001-03-16 14:40 ` RISC Marin David Condic
2001-03-20 10:17 ` RISC Martin Dowie
2001-03-20 14:34 ` RISC Marin David Condic
2001-03-20 15:45 ` RISC Ted Dennison
2001-03-22 9:16 ` RISC - largish (code listed) Martin Dowie
2001-03-22 9:34 ` Martin Dowie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox