Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127364 > unrolled thread
| Started by | Ilias Abrams <iliasabrams@gmail.com> |
|---|---|
| First post | 2018-03-05 08:23 -0800 |
| Last post | 2018-03-06 16:38 +0100 |
| Articles | 20 on this page of 106 — 22 participants |
Back to article view | Back to comp.lang.c
Compile Assembly and C files together Ilias Abrams <iliasabrams@gmail.com> - 2018-03-05 08:23 -0800
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 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 supercat@casperkitty.com - 2018-03-06 07:57 -0800
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-06 16:35 +0000
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-06 18:15 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-06 18:51 +0000
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-06 19:22 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-06 19:30 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-06 12:31 -0800
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-06 23:05 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 12:17 +0100
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 16:05 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 16:45 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 17:54 +0100
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 16:59 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 17:13 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 12:26 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 14:25 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 15:57 +0100
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-07 15:24 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 17:56 +0100
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 11:37 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 13:11 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 15:47 +0100
Re: Compile Assembly and C files together Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-07 07:31 -0800
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 21:00 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 12:33 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-08 13:05 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 15:14 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-08 15:23 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 23:22 +0100
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-08 14:40 -0800
Re: Compile Assembly and C files together Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-08 23:59 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-08 16:54 -0800
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 10:37 +0100
Re: Compile Assembly and C files together Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-09 10:47 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-09 09:19 -0800
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 10:23 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 12:28 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 16:43 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 17:14 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-09 09:32 -0800
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-08 15:26 +0000
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-08 19:23 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 23:27 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-08 16:17 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 23:47 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 11:59 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-07 09:13 -0800
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-07 17:42 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-07 10:55 -0800
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 supercat@casperkitty.com - 2018-03-09 10:12 -0800
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 supercat@casperkitty.com - 2018-03-09 11:45 -0800
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 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
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 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
Re: Compile Assembly and C files together Richard Kettlewell <invalid@invalid.invalid> - 2018-03-06 15:29 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-06 16:38 +0100
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Ilias Abrams <iliasabrams@gmail.com> |
|---|---|
| Date | 2018-03-05 08:23 -0800 |
| Subject | Compile Assembly and C files together |
| Message-ID | <1b658afd-6921-4185-a680-d73f28a95d71@googlegroups.com> |
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
[toc] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2018-03-06 19:20 +0800 |
| Message-ID | <p7ltie$8t5$3@toylet.eternal-september.org> |
| In reply to | #127364 |
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] | [prev] | [next] | [standalone]
| From | druck <news@druck.org.uk> |
|---|---|
| Date | 2018-03-06 13:53 +0000 |
| Message-ID | <p7m6g4$93a$1@dont-email.me> |
| In reply to | #127379 |
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]
| From | Rob Morley <nospam@ntlworld.com> |
|---|---|
| Date | 2018-03-06 14:59 +0000 |
| Message-ID | <20180306145910.01512e6b@Mars> |
| In reply to | #127380 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-06 16:35 +0100 |
| Message-ID | <p7mcge$oci$1@dont-email.me> |
| In reply to | #127381 |
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-06 07:57 -0800 |
| Message-ID | <09640d63-f1b3-43c5-970d-4ac66db41cf3@googlegroups.com> |
| In reply to | #127384 |
On Tuesday, March 6, 2018 at 9:35:52 AM UTC-6, David Brown wrote:
> On 06/03/18 15:59, Rob Morley wrote:
> > 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.
If one needs to use a small assembly-language routine to accomplish some
purpose, and won't be writing a lot of assembly language on the development
system, letting a compiler generate a stub function for e.g.
extern volatile void*pp1,*pp2;
extern volatile int nn;
long multiply_accumulate(void *p1, void *p2, int n)
{
pp1 = p1;
pp2 = p2;
nn = n;
return nn;
}
and then editing in the actual machine instructions one needs, along with
a human-readable prologue etc. is apt to be much faster than reading through
all of the documentation to find out everything the development system will
need. If one ensures that one saves and restores any registers or CPU state
that one disturbs, and sets any CPU states upon which one relies, this
approach should be safe. Reading the documentation may allow one to avoid
redundantly saving/restoring state that calling code would never rely upon,
but if the machine code is either being used to fully encapsulate a time-
critical loop, or is used to accomplish some non-time-critical task that
C simply can't do, saving/restoring extra state should be harmless.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-06 16:35 +0000 |
| Message-ID | <hrznC.15256$5c2.6550@fx09.am4> |
| In reply to | #127388 |
On 06/03/2018 15:57, supercat@casperkitty.com wrote:
> On Tuesday, March 6, 2018 at 9:35:52 AM UTC-6, David Brown wrote:
>> On 06/03/18 15:59, Rob Morley wrote:
>>> 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.
>
> If one needs to use a small assembly-language routine to accomplish some
> purpose, and won't be writing a lot of assembly language on the development
> system, letting a compiler generate a stub function for e.g.
>
> extern volatile void*pp1,*pp2;
> extern volatile int nn;
>
> long multiply_accumulate(void *p1, void *p2, int n)
> {
> pp1 = p1;
> pp2 = p2;
> nn = n;
> return nn;
> }
>
> and then editing in the actual machine instructions one needs, along with
> a human-readable prologue etc. is apt to be much faster than reading through
> all of the documentation to find out everything the development system will
> need. If one ensures that one saves and restores any registers or CPU state
> that one disturbs, and sets any CPU states upon which one relies, this
> approach should be safe. Reading the documentation may allow one to avoid
> redundantly saving/restoring state that calling code would never rely upon,
> but if the machine code is either being used to fully encapsulate a time-
> critical loop, or is used to accomplish some non-time-critical task that
> C simply can't do, saving/restoring extra state should be harmless.
This is the method I've played with for tweaking code on the ARM32 where
I wasn't familiar with the assembly code.
(And also what I had once planned to use to optimise an interpreter for
ARM32: create a module with a set of 200 functions in C which are
wrappers around the the byte-code handlers proper in another module.
To start with, each wrapper just calls the regular function. But by
generating the .s file (compiled with -S, and -O0 to ensure no funny
business), I can optimise selected functions in the assembly file, and
do that incrementally to get better performance. I can also try and keep
essential variables in global registers.
However I never got round to it as I don't use ARM64 enough.)
The important thing though is not to let gcc optimise the code. (Also,
don't accidentally re-compile the original .c file, as it will wipe out
any modifications you've made to the .s file!)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-06 18:15 +0000 |
| Message-ID | <slrnp9tmm0.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127392 |
On Tue, 2018-03-06, bartc wrote:
> On 06/03/2018 15:57, supercat@casperkitty.com wrote:
>> On Tuesday, March 6, 2018 at 9:35:52 AM UTC-6, David Brown wrote:
>>> On 06/03/18 15:59, Rob Morley wrote:
>>>> 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.
>>
>> If one needs to use a small assembly-language routine to accomplish some
>> purpose, and won't be writing a lot of assembly language on the development
>> system, letting a compiler generate a stub function for e.g.
>>
>> extern volatile void*pp1,*pp2;
>> extern volatile int nn;
>>
>> long multiply_accumulate(void *p1, void *p2, int n)
>> {
>> pp1 = p1;
>> pp2 = p2;
>> nn = n;
>> return nn;
>> }
>>
>> and then editing in the actual machine instructions one needs, along with
>> a human-readable prologue etc. is apt to be much faster than reading through
>> all of the documentation to find out everything the development system will
>> need. If one ensures that one saves and restores any registers or CPU state
>> that one disturbs, and sets any CPU states upon which one relies, this
>> approach should be safe. Reading the documentation may allow one to avoid
>> redundantly saving/restoring state that calling code would never rely upon,
>> but if the machine code is either being used to fully encapsulate a time-
>> critical loop, or is used to accomplish some non-time-critical task that
>> C simply can't do, saving/restoring extra state should be harmless.
>
> This is the method I've played with for tweaking code on the ARM32 where
> I wasn't familiar with the assembly code.
>
> (And also what I had once planned to use to optimise an interpreter for
> ARM32: create a module with a set of 200 functions in C which are
> wrappers around the the byte-code handlers proper in another module.
>
> To start with, each wrapper just calls the regular function. But by
> generating the .s file (compiled with -S, and -O0 to ensure no funny
> business), I can optimise selected functions in the assembly file, and
> do that incrementally to get better performance. I can also try and keep
> essential variables in global registers.
>
> However I never got round to it as I don't use ARM64 enough.)
>
> The important thing though is not to let gcc optimise the code.
Why? The optimization level cannot change the calling conventions, or
you'd need a copy of e.g. the standard library for each optimization
setting.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-06 18:51 +0000 |
| Message-ID | <MqBnC.71797$_P3.20721@fx28.am4> |
| In reply to | #127398 |
On 06/03/2018 18:15, Jorgen Grahn wrote:
> On Tue, 2018-03-06, bartc wrote:
>> The important thing though is not to let gcc optimise the code.
>
> Why? The optimization level cannot change the calling conventions, or
> you'd need a copy of e.g. the standard library for each optimization
> setting.
There's a huge amount that gcc can do to render the asm output
incomprehensible. Here's a very simple example:
extern int fnx(int,int);
int fna(int a,int b){
return fnx(a,b);
}
We're interested in the asm framework of the fna function. Compiled with
-O0 for x86 (as I don't have ARM handy) you get:
.text
.globl fna
.def fna; .scl 2; .type 32; .endef
.seh_proc fna
fna:
push rbp #
.seh_pushreg rbp
mov rbp, rsp #,
.seh_setframe rbp, 0
sub rsp, 32 #,
.seh_stackalloc 32
.seh_endprologue
mov DWORD PTR 16[rbp], ecx # a, a
mov DWORD PTR 24[rbp], edx # b, b
mov eax, DWORD PTR 24[rbp] # tmp89, b
mov edx, eax #, tmp89
mov ecx, DWORD PTR 16[rbp] #, a
call fnx #
add rsp, 32 #,
pop rbp #
ret
.seh_endproc
You can clearly make out the entry and return sequence, and how the call
to fnx is set up. Remember that the intention is to augment or modify
this with extra code written in ASM.
Now look at the same code compiled with -O3:
.text
.LHOTB0:
.p2align 4,,15
.globl fna
.def fna; .scl 2; .type 32; .endef
.seh_proc fna
fna:
.seh_endprologue
jmp fnx #
.seh_endproc
It's optimised it pretty much out of existence. All that's left is the
label.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-06 19:22 +0000 |
| Message-ID | <slrnp9tqke.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127401 |
On Tue, 2018-03-06, bartc wrote:
> On 06/03/2018 18:15, Jorgen Grahn wrote:
>> On Tue, 2018-03-06, bartc wrote:
>
>>> The important thing though is not to let gcc optimise the code.
>>
>> Why? The optimization level cannot change the calling conventions, or
>> you'd need a copy of e.g. the standard library for each optimization
>> setting.
>
> There's a huge amount that gcc can do to render the asm output
> incomprehensible. Here's a very simple example:
>
> extern int fnx(int,int);
>
> int fna(int a,int b){
> return fnx(a,b);
> }
Seems contrived: it's the only scenario where the compiler can just
offload all of the calling convention stuff on the called function,
which it also does.
The more I think about it, it seems the safe and simple solution is to
just learn the calling conventions. Last time I had to do that was 25
years ago on the Commodore-Amiga ... no doubt things are more
complicated now, but back then it was really easy.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-06 19:30 +0000 |
| Message-ID | <x%BnC.244083$3K4.170002@fx12.am4> |
| In reply to | #127402 |
On 06/03/2018 19:22, Jorgen Grahn wrote:
> On Tue, 2018-03-06, bartc wrote:
>> On 06/03/2018 18:15, Jorgen Grahn wrote:
>>> On Tue, 2018-03-06, bartc wrote:
>>
>>>> The important thing though is not to let gcc optimise the code.
>>>
>>> Why? The optimization level cannot change the calling conventions, or
>>> you'd need a copy of e.g. the standard library for each optimization
>>> setting.
>>
>> There's a huge amount that gcc can do to render the asm output
>> incomprehensible. Here's a very simple example:
>>
>> extern int fnx(int,int);
>>
>> int fna(int a,int b){
>> return fnx(a,b);
>> }
>
> Seems contrived: it's the only scenario where the compiler can just
> offload all of the calling convention stuff on the called function,
> which it also does.
No, this is exactly the kind of skeleton function which you want to see
represented clearly in ASM, before adding in your own code. With -O0,
you could see how the call mechanism worked. You are not interested in
how clever the compiler can be, especially when it doesn't know what
code you're planning to add.
> The more I think about it, it seems the safe and simple solution is to
> just learn the calling conventions. Last time I had to do that was 25
> years ago on the Commodore-Amiga ... no doubt things are more
> complicated now, but back then it was really easy.
They are trying hard to make it as difficult as possible, but in my own
code generating I try and keep it as simple as I can.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-06 12:31 -0800 |
| Message-ID | <ddcef6ce-f53d-43d7-8f53-7032e68ba7d1@googlegroups.com> |
| In reply to | #127403 |
On Tuesday, March 6, 2018 at 1:30:48 PM UTC-6, Bart wrote:
> On 06/03/2018 19:22, Jorgen Grahn wrote:
> > On Tue, 2018-03-06, bartc wrote:
> >> On 06/03/2018 18:15, Jorgen Grahn wrote:
> >>> On Tue, 2018-03-06, bartc wrote:
> >>
> >>>> The important thing though is not to let gcc optimise the code.
> >>>
> >>> Why? The optimization level cannot change the calling conventions, or
> >>> you'd need a copy of e.g. the standard library for each optimization
> >>> setting.
> >>
> >> There's a huge amount that gcc can do to render the asm output
> >> incomprehensible. Here's a very simple example:
> >>
> >> extern int fnx(int,int);
> >>
> >> int fna(int a,int b){
> >> return fnx(a,b);
> >> }
> >
> > Seems contrived: it's the only scenario where the compiler can just
> > offload all of the calling convention stuff on the called function,
> > which it also does.
>
> No, this is exactly the kind of skeleton function which you want to see
> represented clearly in ASM, before adding in your own code. With -O0,
> you could see how the call mechanism worked. You are not interested in
> how clever the compiler can be, especially when it doesn't know what
> code you're planning to add.
Writing every parameter to a volatile variable will generally force the
compiler to produce code which uses all the parameters is easily-
recognizable fashion. Learning platform calling conventions won't be
enough if unless the directives used by the toolset's assembler match
what one is used to. If someone is using a particular vendor's assembler
on many platforms, it's often convenient to have directives that work
the same way on all of them. Unfortunately, such compatibility among
compilers from the same vendor means that assemblers from different
vendors will often be incompatible even when targeting the same platform.
> > The more I think about it, it seems the safe and simple solution is to
> > just learn the calling conventions. Last time I had to do that was 25
> > years ago on the Commodore-Amiga ... no doubt things are more
> > complicated now, but back then it was really easy.
>
> They are trying hard to make it as difficult as possible, but in my own
> code generating I try and keep it as simple as I can.
Learning calling conventions is often not enough. Knowing how a particular
vendor's tools want things like code and data sections to be set up is
necessary as well.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-06 23:05 +0000 |
| Message-ID | <E8FnC.50608$MY2.27227@fx21.iad> |
| In reply to | #127405 |
supercat@casperkitty.com writes: >Writing every parameter to a volatile variable will generally force the >compiler to produce code which uses all the parameters is easily- >recognizable fashion. Learning platform calling conventions won't be >enough if unless the directives used by the toolset's assembler match >what one is used to. Of course on unix and linux systems, one simply downloads the appropriate processor-specific ABI which documents in fine detail the calling conventions - specifically to allow inter-language interoperability. E.g. the psABI for x86_64.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-07 12:17 +0100 |
| Message-ID | <p7ohnt$po$1@dont-email.me> |
| In reply to | #127398 |
On 06/03/18 19:15, Jorgen Grahn wrote:
> On Tue, 2018-03-06, bartc wrote:
>> On 06/03/2018 15:57, supercat@casperkitty.com wrote:
>>> On Tuesday, March 6, 2018 at 9:35:52 AM UTC-6, David Brown wrote:
>>>> On 06/03/18 15:59, Rob Morley wrote:
>>>>> 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.
>>>
>>> If one needs to use a small assembly-language routine to accomplish some
>>> purpose, and won't be writing a lot of assembly language on the development
>>> system, letting a compiler generate a stub function for e.g.
>>>
>>> extern volatile void*pp1,*pp2;
>>> extern volatile int nn;
>>>
>>> long multiply_accumulate(void *p1, void *p2, int n)
>>> {
>>> pp1 = p1;
>>> pp2 = p2;
>>> nn = n;
>>> return nn;
>>> }
>>>
>>> and then editing in the actual machine instructions one needs, along with
>>> a human-readable prologue etc. is apt to be much faster than reading through
>>> all of the documentation to find out everything the development system will
>>> need. If one ensures that one saves and restores any registers or CPU state
>>> that one disturbs, and sets any CPU states upon which one relies, this
>>> approach should be safe. Reading the documentation may allow one to avoid
>>> redundantly saving/restoring state that calling code would never rely upon,
>>> but if the machine code is either being used to fully encapsulate a time-
>>> critical loop, or is used to accomplish some non-time-critical task that
>>> C simply can't do, saving/restoring extra state should be harmless.
>>
>> This is the method I've played with for tweaking code on the ARM32 where
>> I wasn't familiar with the assembly code.
>>
>> (And also what I had once planned to use to optimise an interpreter for
>> ARM32: create a module with a set of 200 functions in C which are
>> wrappers around the the byte-code handlers proper in another module.
>>
>> To start with, each wrapper just calls the regular function. But by
>> generating the .s file (compiled with -S, and -O0 to ensure no funny
>> business), I can optimise selected functions in the assembly file, and
>> do that incrementally to get better performance. I can also try and keep
>> essential variables in global registers.
>>
>> However I never got round to it as I don't use ARM64 enough.)
>>
>> The important thing though is not to let gcc optimise the code.
>
> Why? The optimization level cannot change the calling conventions, or
> you'd need a copy of e.g. the standard library for each optimization
> setting.
>
Perhaps he just wants to make poorer quality code from the compiler, so
that he can pretend the hand-made assembly is better? Maybe he doesn't
want to read the documentation, and learn how to integrate assembly with
the compiler generation? A key point is that if you call assembly code
from the C code, the assembly has to follow the rules of C regarding
which data can be accessed, and it has to follow the rules of the
compiler (or target ABI) regarding register usage. If you have the
compiler in "dumb translator" mode then you can be more flexible, as the
compiler does not take advantage of its knowledge of data and control flow.
Of course, doing this is very fragile - especially as gcc is not a "dumb
translator" even with no optimisation enabled. But some people seem to
think they can use such techniques instead of learning about how to do
it correctly.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-07 16:05 +0000 |
| Message-ID | <slrnpa03eb.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127417 |
On Wed, 2018-03-07, David Brown wrote: > On 06/03/18 19:15, Jorgen Grahn wrote: >> On Tue, 2018-03-06, bartc wrote: ... >>> The important thing though is not to let gcc optimise the code. >> >> Why? The optimization level cannot change the calling conventions, or >> you'd need a copy of e.g. the standard library for each optimization >> setting. >> > > Perhaps he just wants to make poorer quality code from the compiler, so > that he can pretend the hand-made assembly is better? Maybe he doesn't > want to read the documentation, and learn how to integrate assembly with > the compiler generation? Sounds likely; I mostly wanted to oppose the idea that calling conventions change with optimization. (Not sure if that was his idea, but it was easy to get that impression.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-07 16:45 +0000 |
| Message-ID | <uGUnC.244480$3K4.25330@fx12.am4> |
| In reply to | #127432 |
On 07/03/2018 16:05, Jorgen Grahn wrote: > On Wed, 2018-03-07, David Brown wrote: >> On 06/03/18 19:15, Jorgen Grahn wrote: >>> On Tue, 2018-03-06, bartc wrote: > ... >>>> The important thing though is not to let gcc optimise the code. >>> >>> Why? The optimization level cannot change the calling conventions, or >>> you'd need a copy of e.g. the standard library for each optimization >>> setting. >>> >> >> Perhaps he just wants to make poorer quality code from the compiler, so >> that he can pretend the hand-made assembly is better? Maybe he doesn't >> want to read the documentation, and learn how to integrate assembly with >> the compiler generation? > > Sounds likely; I mostly wanted to oppose the idea that calling > conventions change with optimization. (Not sure if that was his idea, > but it was easy to get that impression.) They can do. If a compiler knows that B() will only ever be called from A(), then it can generate whatever code is best, no matter what the API says. That includes inlining B(). And in my example, the normal entry/exit code needed to conform to the ABI, and which was present with -O0, was eliminated completely with -O3, to just a jump. It shows that when you have a chain of calls, some overheads can be removed. But in my example, you need those overheads in place as they may be needed when you put real code into the function via the .s file; the compiler doesn't know that. It assumes the code submitted to it (as .c) is the code that is to be run. This is why you want more conservative asm code as a start point. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-07 17:54 +0100 |
| Message-ID | <p7p5fp$gee$1@dont-email.me> |
| In reply to | #127436 |
On 07/03/18 17:45, bartc wrote: > On 07/03/2018 16:05, Jorgen Grahn wrote: >> On Wed, 2018-03-07, David Brown wrote: >>> On 06/03/18 19:15, Jorgen Grahn wrote: >>>> On Tue, 2018-03-06, bartc wrote: >> ... >>>>> The important thing though is not to let gcc optimise the code. >>>> >>>> Why? The optimization level cannot change the calling conventions, or >>>> you'd need a copy of e.g. the standard library for each optimization >>>> setting. >>>> >>> >>> Perhaps he just wants to make poorer quality code from the compiler, so >>> that he can pretend the hand-made assembly is better? Maybe he doesn't >>> want to read the documentation, and learn how to integrate assembly with >>> the compiler generation? >> >> Sounds likely; I mostly wanted to oppose the idea that calling >> conventions change with optimization. (Not sure if that was his idea, >> but it was easy to get that impression.) > Some people make additional assumptions about code generation beyond what you get in the ABI - such as assuming when and how data is written to memory, or which registers are used for which purpose. It is, of course, a terrible idea - but some people do it. > They can do. No, they can't. > If a compiler knows that B() will only ever be called from > A(), then it can generate whatever code is best, no matter what the API > says. That includes inlining B(). > If B() is declared with external linkage, the compiler will generate code that allows it to be used externally using the ABI for the target (and compiler). It might /also/ generate inlined versions, or clones with different calling conventions, or clones with partial inlining, or other optimisation. > And in my example, the normal entry/exit code needed to conform to the > ABI, and which was present with -O0, was eliminated completely with -O3, > to just a jump. It shows that when you have a chain of calls, some > overheads can be removed. Of course - normally you don't want more overhead and entry/exit code than is actually necessary. > > But in my example, you need those overheads in place as they may be > needed when you put real code into the function via the .s file; the > compiler doesn't know that. It assumes the code submitted to it (as .c) > is the code that is to be run. No, the compiler is perfectly happy with code written in any supported language, including assembly - it just needs to follow the rules of the ABI. Your assembly code - even if it is in an external .s file - does not need any more entry/exit code than required by the ABI. > > This is why you want more conservative asm code as a start point. > Perhaps /you/ want it, but it is certainly not required. At best it might give you a higher chance of working than pure guesswork, but it is no substitution for actually learning what you are doing.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-07 16:59 +0000 |
| Message-ID | <slrnpa06k0.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127436 |
On Wed, 2018-03-07, bartc wrote: > On 07/03/2018 16:05, Jorgen Grahn wrote: >> On Wed, 2018-03-07, David Brown wrote: >>> On 06/03/18 19:15, Jorgen Grahn wrote: >>>> On Tue, 2018-03-06, bartc wrote: >> ... >>>>> The important thing though is not to let gcc optimise the code. >>>> >>>> Why? The optimization level cannot change the calling conventions, or >>>> you'd need a copy of e.g. the standard library for each optimization >>>> setting. >>>> >>> >>> Perhaps he just wants to make poorer quality code from the compiler, so >>> that he can pretend the hand-made assembly is better? Maybe he doesn't >>> want to read the documentation, and learn how to integrate assembly with >>> the compiler generation? >> >> Sounds likely; I mostly wanted to oppose the idea that calling >> conventions change with optimization. (Not sure if that was his idea, >> but it was easy to get that impression.) > > They can do. If a compiler knows that B() will only ever be called from > A(), then it can generate whatever code is best, no matter what the API > says. That includes inlining B(). I assumed the context was calls between translation units, with no link-time optimization -- such as you'd get if one translation unit was in assembly. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-07 17:13 +0000 |
| Message-ID | <g5VnC.244481$3K4.72565@fx12.am4> |
| In reply to | #127439 |
On 07/03/2018 16:59, Jorgen Grahn wrote: > On Wed, 2018-03-07, bartc wrote: >> On 07/03/2018 16:05, Jorgen Grahn wrote: >>> On Wed, 2018-03-07, David Brown wrote: >>>> On 06/03/18 19:15, Jorgen Grahn wrote: >>>>> On Tue, 2018-03-06, bartc wrote: >>> ... >>>>>> The important thing though is not to let gcc optimise the code. >>>>> >>>>> Why? The optimization level cannot change the calling conventions, or >>>>> you'd need a copy of e.g. the standard library for each optimization >>>>> setting. >>>>> >>>> >>>> Perhaps he just wants to make poorer quality code from the compiler, so >>>> that he can pretend the hand-made assembly is better? Maybe he doesn't >>>> want to read the documentation, and learn how to integrate assembly with >>>> the compiler generation? >>> >>> Sounds likely; I mostly wanted to oppose the idea that calling >>> conventions change with optimization. (Not sure if that was his idea, >>> but it was easy to get that impression.) >> >> They can do. If a compiler knows that B() will only ever be called from >> A(), then it can generate whatever code is best, no matter what the API >> says. That includes inlining B(). > > I assumed the context was calls between translation units, with no > link-time optimization -- such as you'd get if one translation unit > was in assembly. I have a compiler, not for C, that generates code for x64 with its hefty ABI, but which uses its own call convention including across modules. It only uses the official ABI for calling foreign functions, and for callbacks. With a C compiler, that is more difficult to do, as it's harder to distinguish between C functions compiled in your source code, and only called from other parts of your source code, and other C functions both inside and outside your application. But I think that still doesn't preclude a C implementation inventing a private call convention and optionally using that, even across modules, but not for exporting outside the application. In the OP's example using gcc, that wouldn't apply. Still, there's a lot an optimsing compiler can do that would generate highly confusing ASM output, but that would still effectively operate within the ABI rules. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-07 12:26 +0100 |
| Message-ID | <p7oi8l$480$1@dont-email.me> |
| In reply to | #127392 |
On 06/03/18 17:35, bartc wrote: > To start with, each wrapper just calls the regular function. But by > generating the .s file (compiled with -S, and -O0 to ensure no funny > business), I can optimise selected functions in the assembly file, and > do that incrementally to get better performance. I can also try and keep > essential variables in global registers. > Just for your information - you know that with gcc you can also choose to optimise different functions in different ways? And you can also put global variables directly in registers. You don't want to do that very often, as it limits other code generation, but it can be useful on occasion.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web