Prev: Barrier re-evaluation issue with GNAT 4.3.2
Next: GTKADA Installation Questions
From: Gautier write-only on 8 Oct 2009 15:41
On 8 oct, 18:04, Yannick Duchêne Hibou57 <yannick_duch...(a)yahoo.fr>:
> Do some one have examples from other Ada compilers ? (GNAT is not the
> only one).

Sure, for instance Aonix ObjectAda 7.2.2 SE (release mode, optim.
level 2) compiles this (P_in defined as above)...
P_in(i,s);
P_in(5678,s);
P_in(6789,"direct!");
into...
22| 000024 00000000
22| 000028 8B4D MOV ECX, [EBP-8]
22| 00002A F8
22| 00002B 894D MOV [EBP-12], ECX ; i
22| 00002D F4
; Source Line # 23
23| 00002E 68 PUSH __lcl.00000002
23| 00002F 00000000
23| 000033 8D55 LEA EDX, [EBP-4] ; s
23| 000035 FC
23| 000036 52 PUSH EDX
23| 000037 51 PUSH ECX
23| 000038 E8 CALL test_in_out.p_in
23| 000039 00000000
; Source Line # 24
24| 00003D 68 PUSH __lcl.00000002
24| 00003E 00000000
24| 000042 8D75 LEA ESI, [EBP-4] ; s
24| 000044 FC
24| 000045 56 PUSH ESI
24| 000046 68 PUSH 5678
24| 000047 2E160000
24| 00004B E8 CALL test_in_out.p_in
24| 00004C 00000000
; Source Line # 25
25| 000050 68 PUSH __lcl.00000004
25| 000051 00000000
25| 000055 68 PUSH __lcl.00000003
25| 000056 00000000
25| 00005A 68 PUSH 6789
25| 00005B 851A0000
25| 00005F E8 CALL test_in_out.p_in
25| 000060 00000000
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the Web site!
From: Yannick Duchêne Hibou57 on 9 Oct 2009 02:14
On 8 oct, 21:41, Gautier write-only <gautier_niou...(a)hotmail.com>
wrote:
> Sure, for instance Aonix ObjectAda 7.2.2 SE (release mode, optim.
> level 2) compiles this (P_in defined as above)...
>   P_in(i,s);
>   P_in(5678,s);
>   P_in(6789,"direct!");
> into...
>    22| 000024 00000000
>    22| 000028 8B4D                        MOV    ECX, [EBP-8]
>    22| 00002A F8
>    22| 00002B 894D                        MOV    [EBP-12], ECX ;  i
>    22| 00002D F4
> ;  Source Line # 23
>    23| 00002E 68                          PUSH   __lcl.00000002
>    23| 00002F 00000000
>    23| 000033 8D55                        LEA    EDX, [EBP-4] ;  s
>    23| 000035 FC
>    23| 000036 52                          PUSH   EDX
>    23| 000037 51                          PUSH   ECX
>    23| 000038 E8                          CALL   test_in_out.p_in
>    23| 000039 00000000
> ;  Source Line # 24
>    24| 00003D 68                          PUSH   __lcl.00000002
>    24| 00003E 00000000
>    24| 000042 8D75                        LEA    ESI, [EBP-4] ;  s
>    24| 000044 FC
>    24| 000045 56                          PUSH   ESI
>    24| 000046 68                          PUSH   5678
>    24| 000047 2E160000
>    24| 00004B E8                          CALL   test_in_out.p_in
>    24| 00004C 00000000
> ;  Source Line # 25
>    25| 000050 68                          PUSH   __lcl.00000004
>    25| 000051 00000000
>    25| 000055 68                          PUSH   __lcl.00000003
>    25| 000056 00000000
>    25| 00005A 68                          PUSH   6789
>    25| 00005B 851A0000
>    25| 00005F E8                          CALL   test_in_out.p_in
>    25| 000060 00000000

Thanks for the Gesture :)

It's a long time I haven't seen a LEA (load effective address) in an
assembly listing

That's strange : the opcode 16#E8# stands for a Call instruction which
is encoded with a relative offset, and the relative offset is always
zero (16#00000000#) here, whatever is the location of the Call
instance. It's funny (there must be a trick somewhere).
From: sjw on 9 Oct 2009 14:51
On Oct 9, 7:14 am, Yannick Duchêne Hibou57 <yannick_duch...(a)yahoo.fr>
wrote:
> On 8 oct, 21:41, Gautier write-only <gautier_niou...(a)hotmail.com>
> wrote:
[..]
> >    25| 00005F E8                          CALL   test_in_out.p_in
> >    25| 000060 00000000
>
> Thanks for the Gesture :)
>
> It's a long time I haven't seen a LEA (load effective address) in an
> assembly listing
>
> That's strange : the opcode 16#E8# stands for a Call instruction which
> is encoded with a relative offset, and the relative offset is always
> zero (16#00000000#) here, whatever is the location of the Call
> instance. It's funny (there must be a trick somewhere).

Presumably it's fixed up at link time.
First  |  Prev  | 
Pages: 1 2 3
Prev: Barrier re-evaluation issue with GNAT 4.3.2
Next: GTKADA Installation Questions