Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.raspberry-pi > #16591 > unrolled thread

Re: Compile Assembly and C files together

Back to article view | Back to comp.sys.raspberry-pi

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-06 19:20 +0800
    Re: Compile Assembly and C files together jack4747@gmail.com - 2018-03-06 05:12 -0800
    Re: Compile Assembly and C files together druck <news@druck.org.uk> - 2018-03-06 13:53 +0000
      Re: Compile Assembly and C files together Rob Morley <nospam@ntlworld.com> - 2018-03-06 14:59 +0000
        Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-06 16:35 +0100
      Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-06 23:01 +0800
    Re: Compile Assembly and C files together ray carter <ray@zianet.com> - 2018-03-06 15:44 +0000
      Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-07 00:07 +0800
        Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-07 22:39 +0200
          Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-08 18:18 +0800
            Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 12:37 +0000
              Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 13:13 +0000
                Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-08 13:34 +0000
                  Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 15:27 +0000
                    Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-08 17:33 +0000
                      Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:06 +0000
                        Re: Compile Assembly and C files together Richard Kettlewell <invalid@invalid.invalid> - 2018-03-09 09:17 +0000
                          Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:30 +0000
                            Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 15:56 +0200
                              Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 14:13 +0000
                                Re: Compile Assembly and C files together Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2018-03-09 11:14 -0500
                                  Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:44 +0000
                                Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 17:16 +0100
                                  Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 11:19 -0600
                                    Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 18:11 +0000
                                      Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 13:41 -0600
                                    Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 19:20 +0100
                                      Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 13:48 -0600
                                  Re: Compile Assembly and C files together Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2018-03-09 13:16 -0500
                                    Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 18:29 +0000
                                      Re: Compile Assembly and C files together Jack Fearnley <jack@alcor.concordia.ca> - 2018-03-09 19:07 +0000
                                        Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 19:13 +0000
                                          Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-10 13:16 -0600
                                            Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-11 19:39 +0000
                                              Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 01:16 -0500
                                                Re: Compile Assembly and C files together David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2018-03-12 06:39 +0000
                                                Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-12 20:49 +0000
                                              Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:11 +0000
                                                Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 14:58 -0500
                                                  Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 20:38 +0000
                                            Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:06 +0000
                                              Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 14:58 -0500
                                    Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:27 +0200
                              Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:40 +0000
                                Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:30 +0200
                              Re: Compile Assembly and C files together Richard Damon <Richard@Damon-Family.org> - 2018-03-09 13:16 -0500
                                Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:33 +0200
                        Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-09 17:40 +0000
                          Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:47 +0000
                            Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-09 18:05 +0000
                      Compile Assembly and C files together nospam.mark.lewis@p73.f12.n3634.z1.binkp.net (mark lewis) - 2018-03-09 04:17 +1200
                    Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:05 +0000
                      Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 16:01 +0200
              Re: Compile Assembly and C files together jack4747@gmail.com - 2018-03-08 05:46 -0800
                Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-08 14:47 +0000
            Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-08 17:25 +0200
    Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-07 07:36 +0000

Page 1 of 3  [1] 2 3  Next page →

#16591 — Re: Compile Assembly and C files together

On 6/3/2018 00:23, Ilias Abrams wrote:
> Hi guys, can a kindly soul explain to me how I can compile a .c file with an .asm file together on a RPI 2?  I have an assembly file that I am calling a function through a C code.  What I need to do now so I can combine and compile both files togethe

You talking about inline Assembly? You could the ASM compiler directive?

Or a makefile including an external ASM source file? The latter scenario 
needs an external assembly compiler.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不賭錢! 不援交! 不打交! 不打劫! 不自殺! 不求神! 請考慮綜援 
(CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [next] | [standalone]

#16592

Il giorno martedì 6 marzo 2018 12:20:47 UTC+1, Mr. Man-wai Chang ha scritto:
> On 6/3/2018 00:23, Ilias Abrams wrote:
> > Hi guys, can a kindly soul explain to me how I can compile a .c file with an .asm file together on a RPI 2?  I have an assembly file that I am calling a function through a C code.  What I need to do now so I can combine and compile both files togethe
> 
> You talking about inline Assembly? You could the ASM compiler directive?
> 
> Or a makefile including an external ASM source file? The latter scenario 
> needs an external assembly compiler.

This has nothing to do with the RPi.
You have to check how your compiler (I assume gcc) handles .asm and .c files.
GCC documentation and Google are your frineds.

Bye Jack

[toc] | [prev] | [next] | [standalone]

#16593

On 06/03/18 11:20, Mr. Man-wai Chang wrote:
> On 6/3/2018 00:23, Ilias Abrams wrote:
>> Hi guys, can a kindly soul explain to me how I can compile a .c file 
>> with an .asm file together on a RPI 2?  I have an assembly file that I 
>> am calling a function through a C code.  What I need to do now so I 
>> can combine and compile both files togethe
> 
> You talking about inline Assembly? You could the ASM compiler directive?
> 
> Or a makefile including an external ASM source file? The latter scenario 
> needs an external assembly compiler.

The easiest way to do the latter, is to write a C stub for the function 
which you wish to write in assembler, then compile this with gcc -S to 
produce a template asm file with the correct register bindings which you 
can then fill out.

---druck

[toc] | [prev] | [next] | [standalone]

#16594

On Tue, 6 Mar 2018 13:53:05 +0000
druck <news@druck.org.uk> wrote:
 
> The easiest way to do the latter, is to write a C stub for the
> function which you wish to write in assembler, then compile this with
> gcc -S to produce a template asm file with the correct register
> bindings which you can then fill out.
> 
That's handy.  Although the last time I wrote any assembler was about
20 years ago, I still might ...

[toc] | [prev] | [next] | [standalone]

#16596

On 06/03/18 15:59, Rob Morley wrote:
> On Tue, 6 Mar 2018 13:53:05 +0000
> druck <news@druck.org.uk> wrote:
>  
>> The easiest way to do the latter, is to write a C stub for the
>> function which you wish to write in assembler, then compile this with
>> gcc -S to produce a template asm file with the correct register
>> bindings which you can then fill out.
>>
> That's handy.  Although the last time I wrote any assembler was about
> 20 years ago, I still might ...
> 

It is not good advice.  At best it gives you a very limited idea of the
calling conventions and registers usage.  If you really want to write
pure assembly functions that interact with code in other languages, you
have to read up on the calling conventions and ABI for the target (and,
if it is Windows, for the compiler you are using - the ABI is not
standardised on Windows).

If you are using gcc (or clang, or icc, or a few other compilers) and
you are writing short pieces of assembly, you would be better off
learning about gcc's inline assembly support.  Then the compiler takes
care of all the interface between the assembly and C.

[toc] | [prev] | [next] | [standalone]

#16595

On 6/3/2018 21:53, druck wrote:
> On 06/03/18 11:20, Mr. Man-wai Chang wrote:
>> On 6/3/2018 00:23, Ilias Abrams wrote:
>>> Hi guys, can a kindly soul explain to me how I can compile a .c file
>>> with an .asm file together on a RPI 2?  I have an assembly file that
>>> I am calling a function through a C code.  What I need to do now so I
>>> can combine and compile both files togethe
>>
>> You talking about inline Assembly? You could the ASM compiler directive?
>>
>> Or a makefile including an external ASM source file? The latter
>> scenario needs an external assembly compiler.
>
> The easiest way to do the latter, is to write a C stub for the function
> which you wish to write in assembler, then compile this with gcc -S to
> produce a template asm file with the correct register bindings which you
> can then fill out.
>
> ---druck

I could remember Turbo C for DOS has inline assembly directives. I think 
Micro$oft C for DOS had it as well. Not sure about modern Visual C, C++, 
C#. Um.. I think you could not do that anymore given the complexities of 
Window$.

Anyway, the post mentioned that it's an external file.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不賭錢! 不援交! 不打交! 不打劫! 不自殺! 不求神! 請考慮綜援 
(CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#16597

On Tue, 06 Mar 2018 19:20:45 +0800, Mr. Man-wai Chang wrote:

> On 6/3/2018 00:23, Ilias Abrams wrote:
>> Hi guys, can a kindly soul explain to me how I can compile a .c file
>> with an .asm file together on a RPI 2?  I have an assembly file that I
>> am calling a function through a C code.  What I need to do now so I can
>> combine and compile both files togethe
> 
> You talking about inline Assembly? You could the ASM compiler directive?
> 
> Or a makefile including an external ASM source file? The latter scenario
> needs an external assembly compiler.

Why do you need to 'compile them together'? Assemble to asm to make an 
object file, compile the c to make an object file and then, assuming you 
have the calling sequences correct, link them together to make the 
executable.

[toc] | [prev] | [next] | [standalone]

#16598

On 6/3/2018 23:44, ray carter wrote:
>
> Why do you need to 'compile them together'? Assemble to asm to make an
> object file, compile the c to make an object file and then, assuming you
> have the calling sequences correct, link them together to make the
> executable.

Sounds like a security problem as well, as the EXTERNAL program might 
not follow the secured, managed C compiler. :)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不賭錢! 不援交! 不打交! 不打劫! 不自殺! 不求神! 請考慮綜援 
(CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#16604

On 6.3.18 18:07, Mr. Man-wai Chang wrote:
> On 6/3/2018 23:44, ray carter wrote:
>>
>> Why do you need to 'compile them together'? Assemble to asm to make an
>> object file, compile the c to make an object file and then, assuming you
>> have the calling sequences correct, link them together to make the
>> executable.
> 
> Sounds like a security problem as well, as the EXTERNAL program might 
> not follow the secured, managed C compiler. :)


The standard C compiler on Linux (and Pi) is GCC. It compiles the
C source to assembler and then assembles the code to symbolic
binary code (object, .o file). The objects are then collected
together into the final run file. In the assembly code phase,
the compiled C code *is* just assembler source.

Are you sure that the ssembly code module is compatible with
the ARM arcitecture and instruction set of the Pi?

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#16605

On 8/3/2018 04:39, Tauno Voipio wrote:
>
> Are you sure that the ssembly code module is compatible with
> the ARM arcitecture and instruction set of the Pi?

I have never worked with ARM architecture, mostly x86. No comment on that.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不賭錢! 不援交! 不打交! 不打劫! 不自殺! 不求神! 請考慮綜援 
(CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#16606

On Thu, 08 Mar 2018 18:18:34 +0800, Mr. Man-wai Chang wrote:

> On 8/3/2018 04:39, Tauno Voipio wrote:
>>
>> Are you sure that the ssembly code module is compatible with the ARM
>> arcitecture and instruction set of the Pi?
> 
> I have never worked with ARM architecture, mostly x86. No comment on
> that.

The best suggestion so far would seem to be from druck: write the module 
that will contain the assembler as a prototype and an empty C function:

/* Prototype, put in a header file, myfunction.h  */
int myfunction(int, char*);

/* empty function as the only contents of a source file, myfunction.c */
int myFn(int bufflth, char* buff)
{
  return 0;
}

include a recipe for this module in your Makefile, compile it and then, 
when you know it all compiles and links OK, either
(a) fill the myfunction() body with inline assembler statements
or
(b) grab the assembler source file that gcc produces from it, insert
your assembler code in that and modify the Makefile recipe accordingly.

I'd go with (a) but YMMV.
 

-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#16607

On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:

CORRECTION for stupid typo: 

/* Prototype, put in a header file, myfunction.h  */
 int myfunction(int, char*);
 
/* empty function as the only contents of a source file, myfunction.c */
  int myfunction(int bufflth, char* buff)
  {
    return 0;
  }
  




-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#16608

On 08/03/18 13:13, Martin Gregorie wrote:
> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
> 
> CORRECTION for stupid typo:
> 
> /* Prototype, put in a header file, myfunction.h  */
>   int myfunction(int, char*);
>   
> /* empty function as the only contents of a source file, myfunction.c */
>    int myfunction(int bufflth, char* buff)
>    {
>      return 0;
>    }
>    
> 
> 
> 
> 
I would at least put in a bit more

int myfunction(int bufflth, char* buff)
    {
       return (int)buff[bufflth-1];
    }

So you know where on the stack buff and bufflth are...




-- 
“But what a weak barrier is truth when it stands in the way of an 
hypothesis!”

Mary Wollstonecraft

[toc] | [prev] | [next] | [standalone]

#16612

On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:

> On 08/03/18 13:13, Martin Gregorie wrote:
>> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>> 
>> CORRECTION for stupid typo:
>> 
>> /* Prototype, put in a header file, myfunction.h  */
>>   int myfunction(int, char*);
>>   
>> /* empty function as the only contents of a source file, myfunction.c
>> */
>>    int myfunction(int bufflth, char* buff)
>>    {
>>      return 0;
>>    }
>>    
>>    
>> 
>> 
>> 
> I would at least put in a bit more
> 
> int myfunction(int bufflth, char* buff)
>     {
>        return (int)buff[bufflth-1];
>     }
> 
> So you know where on the stack buff and bufflth are...

Why would you want to know that? All the assembler operations using the 
arguments will be inside myfunction() and, unless the code is calculating 
a result to be returned and used elsewhere, the returned value is 
probably to report success or failure. 


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#16613

On 08/03/2018 15:27, Martin Gregorie wrote:
> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>
>> On 08/03/18 13:13, Martin Gregorie wrote:
>>> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>>>
>>> CORRECTION for stupid typo:
>>>
>>> /* Prototype, put in a header file, myfunction.h  */
>>>    int myfunction(int, char*);
>>>
>>> /* empty function as the only contents of a source file, myfunction.c
>>> */
>>>     int myfunction(int bufflth, char* buff)
>>>     {
>>>       return 0;
>>>     }
>>>
>>>
>>>
>>>
>>>
>> I would at least put in a bit more
>>
>> int myfunction(int bufflth, char* buff)
>>      {
>>         return (int)buff[bufflth-1];
>>      }
>>
>> So you know where on the stack buff and bufflth are...
>
> Why would you want to know that? All the assembler operations using the
> arguments will be inside myfunction() and, unless the code is calculating
> a result to be returned and used elsewhere, the returned value is
> probably to report success or failure.
>
>
If it returns success or failure, why return 1 of 4 billion possible values?

[toc] | [prev] | [next] | [standalone]

#16620

On 08/03/18 17:33, mm0fmf wrote:
> On 08/03/2018 15:27, Martin Gregorie wrote:
>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>
>>> On 08/03/18 13:13, Martin Gregorie wrote:
>>>> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>>>>
>>>> CORRECTION for stupid typo:
>>>>
>>>> /* Prototype, put in a header file, myfunction.h  */
>>>>    int myfunction(int, char*);
>>>>
>>>> /* empty function as the only contents of a source file, myfunction.c
>>>> */
>>>>     int myfunction(int bufflth, char* buff)
>>>>     {
>>>>       return 0;
>>>>     }
>>>>
>>>>
>>>>
>>>>
>>>>
>>> I would at least put in a bit more
>>>
>>> int myfunction(int bufflth, char* buff)
>>>      {
>>>         return (int)buff[bufflth-1];
>>>      }
>>>
>>> So you know where on the stack buff and bufflth are...
>>
>> Why would you want to know that? All the assembler operations using the
>> arguments will be inside myfunction() and, unless the code is calculating
>> a result to be returned and used elsewhere, the returned value is
>> probably to report success or failure.
>>
>>
> If it returns success or failure, why return 1 of 4 billion possible 
> values?
> 
> 
Another personm who has never coded assmebler for C..

It not what you are rurining, its how to access (bufflth, char* buff) 
which are LOCAL stack based variables.


-- 
“Some people like to travel by train because it combines the slowness of 
a car with the cramped public exposure of 
an airplane.”

Dennis Miller

[toc] | [prev] | [next] | [standalone]

#16621

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 08/03/18 17:33, mm0fmf wrote:
>> On 08/03/2018 15:27, Martin Gregorie wrote:
>>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>>> I would at least put in a bit more
>>>>
>>>> int myfunction(int bufflth, char* buff)
>>>>      {
>>>>         return (int)buff[bufflth-1];
>>>>      }
>>>>
>>>> So you know where on the stack buff and bufflth are...
>>>
>>> Why would you want to know that? All the assembler operations using the
>>> arguments will be inside myfunction() and, unless the code is calculating
>>> a result to be returned and used elsewhere, the returned value is
>>> probably to report success or failure.
>>>
>>
>> If it returns success or failure, why return 1 of 4 billion possible
>> values?
>
> Another personm who has never coded assmebler for C..
>
> It not what you are rurining, its how to access (bufflth, char* buff)
> which are LOCAL stack based variables.

The first few args are passed in registers on many modern systems. See
e.g. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
for instance.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#16622

On 09/03/18 09:17, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 08/03/18 17:33, mm0fmf wrote:
>>> On 08/03/2018 15:27, Martin Gregorie wrote:
>>>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>>>> I would at least put in a bit more
>>>>>
>>>>> int myfunction(int bufflth, char* buff)
>>>>>       {
>>>>>          return (int)buff[bufflth-1];
>>>>>       }
>>>>>
>>>>> So you know where on the stack buff and bufflth are...
>>>>
>>>> Why would you want to know that? All the assembler operations using the
>>>> arguments will be inside myfunction() and, unless the code is calculating
>>>> a result to be returned and used elsewhere, the returned value is
>>>> probably to report success or failure.
>>>>
>>>
>>> If it returns success or failure, why return 1 of 4 billion possible
>>> values?
>>
>> Another personm who has never coded assmebler for C..
>>
>> It not what you are rurining, its how to access (bufflth, char* buff)
>> which are LOCAL stack based variables.
> 
> The first few args are passed in registers on many modern systems. See
> e.g. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
> for instance.
> 

Even so, the method still reveals WHICH registers

But it is not a feature of the ARM per se, merely a convention.

I assume gcc follows it, but there is no gurantee






-- 
"If you don’t read the news paper, you are un-informed. If you read the 
news paper, you are mis-informed."

Mark Twain

[toc] | [prev] | [next] | [standalone]

#16625

On 9.3.18 11:30, The Natural Philosopher wrote:
> On 09/03/18 09:17, Richard Kettlewell wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> On 08/03/18 17:33, mm0fmf wrote:
>>>> On 08/03/2018 15:27, Martin Gregorie wrote:
>>>>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>>>>> I would at least put in a bit more
>>>>>>
>>>>>> int myfunction(int bufflth, char* buff)
>>>>>>       {
>>>>>>          return (int)buff[bufflth-1];
>>>>>>       }
>>>>>>
>>>>>> So you know where on the stack buff and bufflth are...
>>>>>
>>>>> Why would you want to know that? All the assembler operations using 
>>>>> the
>>>>> arguments will be inside myfunction() and, unless the code is 
>>>>> calculating
>>>>> a result to be returned and used elsewhere, the returned value is
>>>>> probably to report success or failure.
>>>>>
>>>>
>>>> If it returns success or failure, why return 1 of 4 billion possible
>>>> values?
>>>
>>> Another personm who has never coded assmebler for C..
>>>
>>> It not what you are rurining, its how to access (bufflth, char* buff)
>>> which are LOCAL stack based variables.
>>
>> The first few args are passed in registers on many modern systems. See
>> e.g. 
>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf 
>>
>> for instance.
>>
> 
> Even so, the method still reveals WHICH registers
> 
> But it is not a feature of the ARM per se, merely a convention.
> 
> I assume gcc follows it, but there is no gurantee

GCC follows the ARM EABI specification:

  - stack on 8 byte boundaries,
  - arguments in r0 - r3
  - return value in r0

I still suspect that the OP does not have a clue of the assembly
code he's attempting to link in.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#16627

On 09/03/2018 13:56, Tauno Voipio wrote:
> On 9.3.18 11:30, The Natural Philosopher wrote:

>> Even so, the method still reveals WHICH registers
>>
>> But it is not a feature of the ARM per se, merely a convention.
>>
>> I assume gcc follows it, but there is no gurantee
> 
> GCC follows the ARM EABI specification:
> 
>   - stack on 8 byte boundaries,
>   - arguments in r0 - r3
>   - return value in r0


Somewhat tidier than that for x64, which varies between Windows and 
Linux. Windows has the simpler one, and passes the first four arguments 
in rcx, rdx, r8 and r9.

So not only are the registers not consecutive, but they couldn't even 
come up with a consistent naming scheme for the registers.

/And/ the stack has to be kept at 16-byte alignment, even though 
individual parameters (the ones that have to go on the stack, and shadow 
space for the first four), are all 8 bytes each. That is, it needs to be 
16-byte aligned just before you execute 'call'.

Keeping track of that is a nightmare, and a real problem when writing 
extensive ASM code that has to make calls to conforming functions.

Further (I don't know if this applies to ARM; does it have a separate 
set of floating point registers?), floating point params need to be 
passed in a corresponding floating point register instead, XMM0 to XMM3 
(here, the names /are/ consistent, and they are consecutive!). For 
variadic floating point arguments, they need to be passed in both.

Phew! And that's the easier Win64 ABI.

I guess simplicity of the call convention wasn't a priority.


-- 
bartc

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.sys.raspberry-pi

csiph-web