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

Groups > comp.lang.c > #127364 > unrolled thread

Compile Assembly and C files together

Back to article view | Back to comp.lang.c

Contents

  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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#127532

On 08/03/18 23:40, supercat@casperkitty.com wrote:
> On Thursday, March 8, 2018 at 4:22:35 PM UTC-6, David Brown wrote:
>> The -O3 flag asks gcc to do its best to generate the fastest code, with 
>> a total disregard for readability of the generated code or its size.  So 
>> it unrolls the function calls.  If you wanted to, I am sure you could 
>> work through it to see the logic - but it is not something that anyone 
>> expects.
> 
> The -O3 flag generally causes gcc to presume that loops will iterate a
> large number of times, and generate code which will be more efficient in
> those cases, at the expense of efficiency in cases where the number of
> iterations ends up being smaller.  In some cases, gcc's judgment seems
> rather questionable.  For example, given:
> 
>     void slide_bytes(unsigned char *p)
>     {
>         for (int i=0; i<5; i++)
>             p[i] = p[i+1];
>     }
> 
> it generates a call to memmove equivalent to:
> 
>     void slide_bytes(unsigned char *p)
>     {
>         memmove(p, p+1, 5);
>     }
> 
> even though it would seem unlikely that any implementation of a separately-
> compiled memmove function would be able to beat (or even come close to) the
> performance of machine code that performs a 32-bit load and 8-bit load
> followed by a 32-bit store and 8-bit store.
> 

It is well known that -O3 does not always improve speed over -O2.  A
more common reason is that unrolling and code duplication to eliminate
branches leads to bigger code with with more cache misses.  It is very
hard for a compiler to have algorithms that work well on all possible
types of source code.


Getting /good/ object code from a compiler is usually just a matter of
writing correct C code, and compiling with solid optimisation (-O2 for
gcc).

Getting the /best/ object code involves a lot more work,
experimentation, profiling, reading documentation, trial-and-error,
using different flags, using compiler extensions, using different flags
for different parts of the code.  It is rarely worth the effort.

For my own work, I usually use -O2 along with a few specific flags that
I have found make a helpful difference to the kind of code I write.

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

#127538

On 08/03/2018 22:22, David Brown wrote:
> On 08/03/18 16:23, bartc wrote:

>> I would say this has low correlation to the original C. It's not 
>> technically chaotic, because it is the result of some deterministic 
>> algorithm running inside the compiler. But it might as well be for the 
>> purposes of someone trying to modify the code.
> 
> It is not remotely "chaotic".  That word does not mean what you think it 
> means.
> 
> The -O3 flag asks gcc to do its best to generate the fastest code, with 
> a total disregard for readability of the generated code or its size.

Yes, this is exactly my point. Are you picking on my choice of the word 
'chaotic'?

> Lower optimisation levels generate simpler code that is easier to 
> follow.

And again. If you want to modify the asm, then as a start point you want 
to use the simpler code. Hence my suggestion to not use the optimisation 
flag. In the case of my original example, the code for the function 
disappeared completely, so where are you going to stick your mods?

   There is no "chaotic" behaviour, or "hyper-optimisation", or
> any other wild exaggerations going on.

Sorry, this fib example counts as hyper-optimisation in my book, when it 
gives results that are three times as fast as any other compiler, 
including MSVC.

In fact it makes you suspect if it is actually doing the necessary work.

Recursive fib() is often used as a benchmark to see how well a language 
copes with large numbers of function calls.

In the case of fib(40), you expect 204,668,309 calls to be made. But I 
modified fib.s to insert code to count how often it entered that main 
function entry point, and it was only 14,141,714. You can't put this 
check in the C code, as it will lie.

> Timing this on my machine for calculating fib(40) gives 0.36 seconds for 
> -O0, 0.23 seconds for -O1, 0.21 seconds for -O2, and 0.15 seconds for -O3.

I get 1.3/0.3 seconds for O3/O0 on my Intel 3.2GHz machine. Using gcc 5.1.0.

> If you want clear, understandable code use a lower optimisation level. 
> If you want fast code, use a higher level.
> 
> But none of the versions are suitable for tweaking - you are still 
> completely wrong on that as a suggestion for a good way to write 
> assembly code that works with C, instead of learning the ABI for the 
> platform.

People are obsessed with the "ABI".

The ABI is mainly about calling conventions and what goes in what 
register. You don't usually to modify .s files so as to make function 
calls; you want to do something else.

So you write a small function that does a small amount of typical work, 
and generate a .s file. All the surrounding boilerplate code is in 
place. The example shows what registers could be used as work registers. 
It might show how to access global data (an issue with ARM32).

You will even see what kind of instructions are being used if you are 
unfamiliar with the instruction set.

Then you can work on that core part of the function that you're 
interested in.

What you're saying is that you have disdain for this all amateurish 
hacking around: forget all that, learn the entire instruction set from 
the reference manual for the processor (6 hefty manuals in the case of 
Intel x86, 750 pages for the ARM reference manual). Learn the inline 
assembly syntax for gcc (yes, just gcc), another manual.

In short, this is only worth doing if you first spend six months 
becoming an expert just like you.

Well, some of us disagree.

-- 
bartc

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

#127550

On 09/03/18 13:28, bartc wrote:
> On 08/03/2018 22:22, David Brown wrote:
>> On 08/03/18 16:23, bartc wrote:
> 
>>> I would say this has low correlation to the original C. It's not
>>> technically chaotic, because it is the result of some deterministic
>>> algorithm running inside the compiler. But it might as well be for
>>> the purposes of someone trying to modify the code.
>>
>> It is not remotely "chaotic".  That word does not mean what you think
>> it means.
>>
>> The -O3 flag asks gcc to do its best to generate the fastest code,
>> with a total disregard for readability of the generated code or its size.
> 
> Yes, this is exactly my point. Are you picking on my choice of the word
> 'chaotic'?

I was picking on your phrase "chaotic hyper-optimised code" "fraught
with problems".  If you had meant to say "code with loops unrolled for
speed regardless of size or readability", then that would have been fine.


> 
>> Lower optimisation levels generate simpler code that is easier to follow.
> 
> And again. If you want to modify the asm, then as a start point you want
> to use the simpler code.

I would strongly recommend that you /don't/ start with
compiler-generated code and try to modify it.  That is the whole point.
 It doesn't matter whether the compiler has generated complicated
assembly or simple assembly - don't modify it.

Either work /with/ the compiler, letting it generate as much as
possible, or learn the ABI for the platform and write the function
completely in assembly.  (Usually the first choice is the sensible one -
at least if you are not allergic to learning new ideas.)

At best, looking at generate code can give you some hints towards
writing your own assembly functions - at worst, it leads you into false
assumptions and makes you think that copying is a substitute for learning.

>  Hence my suggestion to not use the optimisation
> flag. In the case of my original example, the code for the function
> disappeared completely, so where are you going to stick your mods?

You don't really want me to answer that, do you? :-)

> 
>   There is no "chaotic" behaviour, or "hyper-optimisation", or
>> any other wild exaggerations going on.
> 
> Sorry, this fib example counts as hyper-optimisation in my book, when it
> gives results that are three times as fast as any other compiler,
> including MSVC.
> 
> In fact it makes you suspect if it is actually doing the necessary work.

What do you mean by "doing the necessary work" ?  Perhaps you mean
something different what C means, and what compilers are supposed to do.

You gave a function definition "fib" which takes an int parameter (let's
assume 32-bit) and gives an int result, with instructions giving a way
to get specific results for any integer from INT_MIN up to and including
46 (since fib(47) > INT_MAX, and signed integer overflow is undefined).

The compiler can generate /any/ code as long as it gives the same
matching results and does not introduce any new observable behaviour.
It can make big code or small code, fast code or slow code.  It can
totally re-arrange the algorithm.  It can keep the check for n <= 2,
then use the powers-of-phi algorithm for other values.  It can
pre-calculate a table of fib(3) .. fib(46).  It could generate this
table on the fly - either once for each call to fib, or keeping the
results across calls.

(Those re-arrangements would be pretty smart - worthy of the term
"hyper-optimised" !)

> 
> Recursive fib() is often used as a benchmark to see how well a language
> copes with large numbers of function calls.

That may well be the case.  But the language/implementation does not
have to handle it as recursive function calls if it can do something
smarter.  Many languages/implementations can turn single recursive calls
into loops in a lot of cases - this is a good thing.

> 
> In the case of fib(40), you expect 204,668,309 calls to be made. But I
> modified fib.s to insert code to count how often it entered that main
> function entry point, and it was only 14,141,714. You can't put this
> check in the C code, as it will lie.

You are using the word "lie" to mean "it does what I asked it to do, not
what I wanted it to do" ?

> 
>> Timing this on my machine for calculating fib(40) gives 0.36 seconds
>> for -O0, 0.23 seconds for -O1, 0.21 seconds for -O2, and 0.15 seconds
>> for -O3.
> 
> I get 1.3/0.3 seconds for O3/O0 on my Intel 3.2GHz machine. Using gcc
> 5.1.0.
> 
>> If you want clear, understandable code use a lower optimisation level.
>> If you want fast code, use a higher level.
>>
>> But none of the versions are suitable for tweaking - you are still
>> completely wrong on that as a suggestion for a good way to write
>> assembly code that works with C, instead of learning the ABI for the
>> platform.
> 
> People are obsessed with the "ABI".
> 
> The ABI is mainly about calling conventions and what goes in what
> register. You don't usually to modify .s files so as to make function
> calls; you want to do something else.
> 

Calling conventions are part of an ABI.  They are not the only part.
Try looking at a document describing a real ABI (i.e., not something
from the Windows world).

But calling conventions and register usage are the key parts here - they
say where your function will receive its parameters, which registers it
can use without preservation, and how to return the result.  Other
things you might want to know are how to access data, alignments and
structures, and requirements for stack layouts (you might not have full
freedom here).

> So you write a small function that does a small amount of typical work,
> and generate a .s file. All the surrounding boilerplate code is in
> place. The example shows what registers could be used as work registers.
> It might show how to access global data (an issue with ARM32).
> 
> You will even see what kind of instructions are being used if you are
> unfamiliar with the instruction set.
> 
> Then you can work on that core part of the function that you're
> interested in.
> 
> What you're saying is that you have disdain for this all amateurish
> hacking around: forget all that, learn the entire instruction set from
> the reference manual for the processor (6 hefty manuals in the case of
> Intel x86, 750 pages for the ARM reference manual). Learn the inline
> assembly syntax for gcc (yes, just gcc), another manual.
> 

I am saying that generating some code and then guessing from there is
amateurish hacking around.  You might learn something, you might make
mistakes - it is certainly not the way to do a proper job.  You might
find it helpful for inspiration, but not for a complete solution.

> In short, this is only worth doing if you first spend six months
> becoming an expert just like you.

Don't be absurd.  Even with the most stubborn determinedness to avoid
understanding, you won't take more than a few hours to learn what you
need about the target ABI for external assembly functions, or for gcc
inline assembly.  It will take you a good while longer than that (and a
lot of practice) if you want to get all the nuances and to be fluent
without access to the reference manuals or a tutorial, but few people
are interested in getting that good.

> 
> Well, some of us disagree.
> 

If you spend half as much time trying the these things as you do in
disagreeing with them, you'd have no problem with using gcc, its
optimisation and its inline assembly.

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

#127556

On 09/03/2018 15:43, David Brown wrote:
> On 09/03/18 13:28, bartc wrote:

> I am saying that generating some code and then guessing from there is
> amateurish hacking around.

That's one of the best ways of getting started with something: commence 
with a working program, and start modifying it to see what happens.

Working from scratch is harder.

   You might learn something, you might make
> mistakes - it is certainly not the way to do a proper job.  You might
> find it helpful for inspiration,

Yes, for learning.

 > but not for a complete solution.

Or, in the proposal I mentioned a few days ago, for starting with an 
empty framework in C (a set of wrapper functions), creating the .s 
version using -O0 (at this point everything still works, but perhaps 1% 
slower because of extra sets of entry/exit code). /Then/ you start 
tweaking so that you cover that 1% and then hopefully a lot more.

> 
>> In short, this is only worth doing if you first spend six months
>> becoming an expert just like you.
> 
> Don't be absurd.  Even with the most stubborn determinedness to avoid
> understanding, you won't take more than a few hours to learn what you
> need about the target ABI for external assembly functions, or for gcc
> inline assembly.  It will take you a good while longer than that (and a
> lot of practice) if you want to get all the nuances and to be fluent
> without access to the reference manuals or a tutorial, but few people
> are interested in getting that good.
> 
>>
>> Well, some of us disagree.
>>
> 
> If you spend half as much time trying the these things as you do in
> disagreeing with them, you'd have no problem with using gcc, its
> optimisation and its inline assembly.

The world doesn't revolve around gcc and it's inline assembly syntax, 
nor the ABI for that matter.

My biggest use of ASM at the moment (some 5000 lines as inline asm 
within functions that are nearly all asm with little HLL), is part of a 
program that runs on x64.

But it completely ignores the Win64 ABI, even though it needs to call 
HLL functions. (At one point it even used 32-bit pointers rather than 64.)

One of the advantages of writing ASM, and doing it properly, is not 
having to kowtow to gcc or its 'register transfer language' or even the 
official ABI, if you want to do something a little off-kilter.

-- 
bartc

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

#127560

On Friday, March 9, 2018 at 9:43:21 AM UTC-6, David Brown wrote:
> I would strongly recommend that you /don't/ start with
> compiler-generated code and try to modify it.  That is the whole point.
>  It doesn't matter whether the compiler has generated complicated
> assembly or simple assembly - don't modify it.

I wouldn't try to adapt the *code* generated by a compiler, but rather use
the compiler to generate all the *other* source text that's needed to let
an assembler process my code and make it available to the compiler.

Although I understand some of the reasons behind assembler complexity, I
find it ironic that in many cases one would have to read less documentation
to determine the binary instructions needed to perform a purpose than to
make an assembler generate the code in question.

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

#127479

David Brown <david.brown@hesbynett.no> writes:
>On 08/03/18 14:05, bartc wrote:

>>> The idea is to describe to the compiler how your
>>> assembly interacts with the rest of the code.  It works well - it has
>>> been around for many years, and has been copied by most of the high
>>> quality compilers.
>> 
>> Copied out of admiration, or because they had to in order to be able to
>> able to compile the same code as gcc compiles?
>
>Go and ask Intel, Apple, Freescale, and other compiler writers.  I would
>expect they followed it for both reasons.  It is the second most
>powerful inline assembly system I know of (Diab Data compilers had a

Now there's a name I haven't heard for 25 years or so.   Are they still
around?  IIRC, they were a Norge company, or at least scandanvian. They
had a good compiler for the Motorola 88k risc processor back in the day.

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

#127493

On Thu, 2018-03-08, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>On 08/03/18 14:05, bartc wrote:
>
>>>> The idea is to describe to the compiler how your
>>>> assembly interacts with the rest of the code.  It works well - it has
>>>> been around for many years, and has been copied by most of the high
>>>> quality compilers.
>>> 
>>> Copied out of admiration, or because they had to in order to be able to
>>> able to compile the same code as gcc compiles?
>>
>>Go and ask Intel, Apple, Freescale, and other compiler writers.  I would
>>expect they followed it for both reasons.  It is the second most
>>powerful inline assembly system I know of (Diab Data compilers had a
>
> Now there's a name I haven't heard for 25 years or so.   Are they still
> around?  IIRC, they were a Norge company, or at least scandanvian. They
> had a good compiler for the Motorola 88k risc processor back in the day.

Sweden, ended in 1990 according to Wikipedia; Wind River took the compiler.
https://en.wikipedia.org/wiki/Dataindustrier_AB

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#127509

On 08/03/18 20:23, Jorgen Grahn wrote:
> On Thu, 2018-03-08, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 08/03/18 14:05, bartc wrote:
>>
>>>>> The idea is to describe to the compiler how your
>>>>> assembly interacts with the rest of the code.  It works well - it has
>>>>> been around for many years, and has been copied by most of the high
>>>>> quality compilers.
>>>>
>>>> Copied out of admiration, or because they had to in order to be able to
>>>> able to compile the same code as gcc compiles?
>>>
>>> Go and ask Intel, Apple, Freescale, and other compiler writers.  I would
>>> expect they followed it for both reasons.  It is the second most
>>> powerful inline assembly system I know of (Diab Data compilers had a
>>
>> Now there's a name I haven't heard for 25 years or so.   Are they still
>> around?  IIRC, they were a Norge company, or at least scandanvian. They
>> had a good compiler for the Motorola 88k risc processor back in the day.
> 

It was their 68k compiler I tried (but we could not justify the price at 
the time), some 20 years ago or so.

gcc lets you have multiple constraints on input operands - like "rm" to 
say the input data can be in a register, or a memory address, whichever 
is most convenient to the compiler at the time.  Diab Data went one 
further and let you specify different sets of assembly for these 
different cases.

Their compiler also had a neat extension that let you specify the 
endianness of data or a pointer explicitly.  gcc has only recently 
gained this as a feature (and the data has to be in a struct).

Certainly it was a very advanced compiler in its day.

(Why can I remember such useless information for 20 years, but still 
forget to take my sandwiches for lunch?)

> Sweden, ended in 1990 according to Wikipedia; Wind River took the compiler.
> https://en.wikipedia.org/wiki/Dataindustrier_AB
> 

And Intel owns Wind River these days.

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

#127483

On 08/03/2018 14:14, David Brown wrote:
> On 08/03/18 14:05, bartc wrote:
>> On 08/03/2018 11:33, David Brown wrote:
>>> On 07/03/18 22:00, bartc wrote:
>>
>>> If you want to use assembly along with gcc, you need to learn how to do
>>> it.
>>
>> This is the problem; I can't be arsed learning something so arcane, and
>> IMO so badly designed. (I anyway would hardly ever use it.)
> 
> If you want to use it at all, learn it.  If you don't want to use it,
> don't learn it.  "Hardly ever use it" is your worst possible option.
> 
> How do you manage to classify it as "arcane" and "badly designed" when
> you have not learned it, not used it, and clearly have not made the
> slightest attempt to understand it or the reasoning behind it?

Because, like a lot of things, you can take an instant dislike to a 
language. Especially when you have extensive experience of how such a 
language /could/ work.

Here are some other people's comments:

"...but there is a whole extra language you need to know to make the 
connection between a chunk of asm code and the world outside that chunk 
of asm code (especially local variables in the same function).

That extra language is difficult and generally not worth it."

"...the obscure syntax gcc has for connecting local variables into 
inline asm."


To you of course, 'difficult' and 'obscure' can NEVER be an indication 
that something could do with looking at.

(Is that actually the case? Have you ever come across any system that 
you considered to be poorly designed, over-engineered, over-complicated, 
too hard to understand, or elicited any such opinion on your part? If 
so, what was your response when simply told you have to RTFM?)

> this makes you look?  You have such a
> strong case of "not invented here" syndrome that you can't see past your
> own navel.

I know how it makes you look; I wouldn't come to you for constructive 
opinions about how to make anything better, because it's always going to 
be good enough. Unless perhaps it's too small, too fast, too simple or 
too sensible!

> I really don't care if you don't like gcc, or any other compiler that
> you didn't write yourself.  But it bugs me that you publicly criticise
> tools that you know /nothing/ about,

No, only to regulars in groups like this. Never to people I don't know 
or to beginners.

> The OP came here looking for some advice.  This is arguably not the
> ideal place for such system-specific information, but we could do a lot
> better if the folks that actually understand C, and can use toolchains,
> were able to help rather than trying to battle the ludicrous
> misunderstandings and prejudices that you spread.

What misunderstandings did I spread in my first couple of posts in the 
thread? I don't remember that I expressed an opinion about gcc or its 
assembly language, inline or otherwise.

I remember I made a throwaway comment about avoiding optimisation when 
getting gcc to generate .s files for the purposes of tweaking, which 
regulars chose to jump on.

You, presumably, would ALWAYS use -O2 or -O3 no matter what the 
circumstances. Because you're clever enough to understand not only the 
difficult code that is produced, but also all the code the compiler has 
decided to leave out!

> RTFM.

Interesting. When I write documentation, when I find some aspect 
difficult to explain, it's usually an indication that something is not 
quite right. So quite often I've simplified and improved an application 
or whatever I was working on, so as to be able to describe it more easily.

Clearly that's something alien to the people who write your favourite tools.

>> Copied out of admiration, or because they had to in order to be able to
>> able to compile the same code as gcc compiles?
> 
> Go and ask Intel, Apple, Freescale, and other compiler writers.  I would
> expect they followed it for both reasons.  It is the second most
> powerful inline assembly system I know of (Diab Data compilers had a
> couple of other features).  When you want to have a good inline assembly
> syntax for your compiler, why not copy such a well-known, widely used,
> and proven solution?

I'm currently involved in generating .asm files with up to 100,000 lines 
of assembly code.

Up to the start of this year, I was using Nasm format and running the 
Nasm assembler, which has millions of complicated features all of which 
you would love, but I have no use for.

Using Nasm to assemble the 100Kloc file would take 40 seconds.

I now use /my own/ assembler; it takes 0.05 seconds. For, as far as I'm 
concerned, exactly the same job: turning a .asm file to .obj.

These things /can be/ that simple.


-- 
bartc

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

#127513

On 08/03/18 17:17, bartc wrote:
> On 08/03/2018 14:14, David Brown wrote:
>> On 08/03/18 14:05, bartc wrote:
>>> On 08/03/2018 11:33, David Brown wrote:
>>>> On 07/03/18 22:00, bartc wrote:
>>>
>>>> If you want to use assembly along with gcc, you need to learn how to do
>>>> it.
>>>
>>> This is the problem; I can't be arsed learning something so arcane, and
>>> IMO so badly designed. (I anyway would hardly ever use it.)
>>
>> If you want to use it at all, learn it.  If you don't want to use it,
>> don't learn it.  "Hardly ever use it" is your worst possible option.
>>
>> How do you manage to classify it as "arcane" and "badly designed" when
>> you have not learned it, not used it, and clearly have not made the
>> slightest attempt to understand it or the reasoning behind it?
> 
> Because, like a lot of things, you can take an instant dislike to a 
> language. Especially when you have extensive experience of how such a 
> language /could/ work.
> 
> Here are some other people's comments:
> 
> "...but there is a whole extra language you need to know to make the 
> connection between a chunk of asm code and the world outside that chunk 
> of asm code (especially local variables in the same function).
> 
> That extra language is difficult and generally not worth it."
> 

Extra "language" ?  That's an absurd exaggeration.  Do you consider 
printf format strings to be an extra language?

> "...the obscure syntax gcc has for connecting local variables into 
> inline asm."
> 
> 
> To you of course, 'difficult' and 'obscure' can NEVER be an indication 
> that something could do with looking at.

Certainly gcc's inline assembly syntax is a bit complex, and I expect 
that most people need to have the manual page open for reference when 
writing it.  I fail to see that as a problem - it is a feature you 
rarely need to use, and it does not matter if it is a bit difficult. 
(If you had to use it often, that would indicate a /real/ problem with 
the compiler.)

Could it be done differently?  Sure.  Could an alternative syntax have 
been neater, or easier to follow?  I expect so.  But I would not expect 
to get /that/ much better while keeping the features and the 
flexibility, and working on pretty much any processor.  (Your syntax is 
certainly no replacement, even though it might be convenient for simple 
cases.)

> 
> (Is that actually the case? Have you ever come across any system that 
> you considered to be poorly designed, over-engineered, over-complicated, 
> too hard to understand, or elicited any such opinion on your part? If 
> so, what was your response when simply told you have to RTFM?)

Of course I have come across such systems.  I can't think of any 
examples where it was something I wanted to use, with reasonable 
documentation, lots of tutorials and web pages, and which many people 
use quite successfully - and then thought that the best idea would be to 
avoid any reading, learning or thinking before deriding it in a public 
forum.

> 
>> this makes you look?  You have such a
>> strong case of "not invented here" syndrome that you can't see past your
>> own navel.
> 
> I know how it makes you look; I wouldn't come to you for constructive 
> opinions about how to make anything better, because it's always going to 
> be good enough. Unless perhaps it's too small, too fast, too simple or 
> too sensible!

gcc's inline assembly syntax /is/ good enough.  It has remained 
unchanged for a great many years, because for the great majority of uses 
it is good enough.  That doesn't mean it could not be improved, or that 
an alternative could not be better - but no one has felt enough need to 
change it to actually do anything about it.  There are many, many other 
things I would change about gcc first.

> 
>> I really don't care if you don't like gcc, or any other compiler that
>> you didn't write yourself.  But it bugs me that you publicly criticise
>> tools that you know /nothing/ about,
> 
> No, only to regulars in groups like this. Never to people I don't know 
> or to beginners.
> 

Why would you criticise them to /anyone/, when you have made no effort 
to understand them or to see why they are the way they are?  There are 
lots of things that you could sensibly criticise about C, gcc, or other 
tools that people regularly use here.  But instead you feel this urge to 
criticise /everything/ about them - any aspect that is mentioned by 
other posters.

>> The OP came here looking for some advice.  This is arguably not the
>> ideal place for such system-specific information, but we could do a lot
>> better if the folks that actually understand C, and can use toolchains,
>> were able to help rather than trying to battle the ludicrous
>> misunderstandings and prejudices that you spread.
> 
> What misunderstandings did I spread in my first couple of posts in the 
> thread? I don't remember that I expressed an opinion about gcc or its 
> assembly language, inline or otherwise.
> 
> I remember I made a throwaway comment about avoiding optimisation when 
> getting gcc to generate .s files for the purposes of tweaking, which 
> regulars chose to jump on.
> 
> You, presumably, would ALWAYS use -O2 or -O3 no matter what the 
> circumstances. Because you're clever enough to understand not only the 
> difficult code that is produced, but also all the code the compiler has 
> decided to leave out!

I usually use -O2, because code size is often relevant for me and -O3 
gives a poorer balance for my needs.  Sometimes I will use -O1 if I 
expect to step through the generated code slowly in a debugger, or study 
the assembly code.

> 
>> RTFM.
> 
> Interesting. When I write documentation, when I find some aspect 
> difficult to explain, it's usually an indication that something is not 
> quite right. So quite often I've simplified and improved an application 
> or whatever I was working on, so as to be able to describe it more easily.
> 
> Clearly that's something alien to the people who write your favourite 
> tools.

Have you actually /read/ the information about inline assembly in gcc? 
Or are you merely condemning it because they wrote a page about it in 
the reference manual?

> 
>>> Copied out of admiration, or because they had to in order to be able to
>>> able to compile the same code as gcc compiles?
>>
>> Go and ask Intel, Apple, Freescale, and other compiler writers.  I would
>> expect they followed it for both reasons.  It is the second most
>> powerful inline assembly system I know of (Diab Data compilers had a
>> couple of other features).  When you want to have a good inline assembly
>> syntax for your compiler, why not copy such a well-known, widely used,
>> and proven solution?
> 
> I'm currently involved in generating .asm files with up to 100,000 lines 
> of assembly code.
> 
> Up to the start of this year, I was using Nasm format and running the 
> Nasm assembler, which has millions of complicated features all of which 
> you would love, but I have no use for.
> 
> Using Nasm to assemble the 100Kloc file would take 40 seconds.
> 
> I now use /my own/ assembler; it takes 0.05 seconds. For, as far as I'm 
> concerned, exactly the same job: turning a .asm file to .obj.
> 
> These things /can be/ that simple.
> 

That is about speed, not simplicity.  I have no good idea why Nasm is 
slow for these files - presumably there is some algorithm in it that 
scales very badly.  I have suggested before that you talk to the Nasm 
folks - I don't remember having seen an answer from you.

Not that the speed of particular assemblers has the slightest bearing on 
your point, of course.

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

#127536

On 08/03/2018 22:47, David Brown wrote:
> On 08/03/18 17:17, bartc wrote:

[Lightweight, simpler alternatives to mainstream tools]

>> Using Nasm to assemble the 100Kloc file would take 40 seconds.
>>
>> I now use /my own/ assembler; it takes 0.05 seconds. For, as far as 
>> I'm concerned, exactly the same job: turning a .asm file to .obj.

>> These things /can be/ that simple.
>>
> 
> That is about speed, not simplicity.

> Not that the speed of particular assemblers has the slightest bearing on 
> your point, of course.

An assembler is a good example because the task to be done is 
straightforward, and there is not a lot to be gained from having a 
larger, slower, more cumbersome product.

It's harder to argue the advantages of smaller, lightweight, nippier 
tools when dealing with build systems or compilers.

One advantage I can see of a big compiler is that the generated code is 
better quality. But it is possible to develop programs rapidly with a 
fast toy compiler, then switch to a mainstream one for production code.


-- 
bartc

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

#127440

On Wednesday, March 7, 2018 at 4:37:23 AM UTC-6, David Brown wrote:
> On 06/03/18 16:57, supercat@casperkitty.com wrote:
> > 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.
> 
> Faster to learn, perhaps - but less accurate, less helpful, and far less
> efficient (and it is often for efficiency that people look to assembly
> in the first place).  It also means you need to write more assembly
> yourself.
> 
> Let us take your "multiply-accumulate" example, and turn it into a
> realistic case rather than your jumbled mixture.
> 
> The key operation is perhaps this function:
> 
> long int mac(long int a, int b, int c) {
> 	return a + (long int) b * c;
> }
> 
> Maybe your real types will be different, but these will do for an example.
> 
> On x86-64, this will be done with code like this:
> 
> mac:
>         movsx   rax, edx
>         movsx   rsi, esi
>         imul    rsi, rax
>         lea     rax, [rsi+rdi]
>         ret
> 
> The generated assembly for your example function gives (with gcc -O2,
> 64-bit Linux target using godbolt.org) :
> 
> multiply_accumulate:
>         mov     DWORD PTR nn[rip], edx
>         movsx   rax, DWORD PTR nn[rip]
>         mov     QWORD PTR pp1[rip], rdi
>         mov     QWORD PTR pp2[rip], rsi
>         ret
> 
> How exactly does that give you /any/ sort of hint as to how to write the
> assembly code for a "mac" function like the one I gave?  It gives you
> some guesses as to which registers might be used for parameters and
> returns, but you'd get that faster with a quick google search.

Let's see... if we take my version and feed it into gcc, I'd end up with
a file that contains all the headers and section declarations needed for
the above along with:

    multiply_accumulate:
        mov     DWORD PTR nn[rip], edx
        mov     QWORD PTR pp1[rip], rdi
        mov     QWORD PTR pp2[rip], rsi
        movsx   rax, DWORD PTR nn[rip]
        ret

I'd say it's pretty clear that p1 is passed in rdi, p2 in rsi, and
nn in edx.  Additionally, the return value goes in rax.  How much
clearer could that get?

Note that the purpose of the function using volatiles is not to show
what code for an actual multiply accumulate function would look like,
but rather to show what the code for a minimal function that receives
(and uses) two pointers and an int should look like.  If I'd tried to
use code that actually resembled the operation to be performed, which
in this case would be:

     long multiply_accumulate2(int *p1, int *p2, int n)
     {
       long total=0;
       while(--n)
         total+=*p1++ + *p2++;
       return total;
     }

the generated code would be over 100 lines long.  Since my reason for
using assembly language would be that I know more about how to perform
the operation efficiently on the target that the compiler does (by a
factor of more than 10 in one real-world case), I really would have no
reason to care how the compiler would do it except to confirm that does
not know how best to handle the operations to be performed.

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

#127443

supercat@casperkitty.com writes:
>On Wednesday, March 7, 2018 at 4:37:23 AM UTC-6, David Brown wrote:
>> On 06/03/18 16:57, supercat@casperkitty.com wrote:
>> > 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.
>> 
>> Faster to learn, perhaps - but less accurate, less helpful, and far less
>> efficient (and it is often for efficiency that people look to assembly
>> in the first place).  It also means you need to write more assembly
>> yourself.
>> 
>> Let us take your "multiply-accumulate" example, and turn it into a
>> realistic case rather than your jumbled mixture.
>> 
>> The key operation is perhaps this function:
>> 
>> long int mac(long int a, int b, int c) {
>> 	return a + (long int) b * c;
>> }
>> 
>> Maybe your real types will be different, but these will do for an example.
>> 
>> On x86-64, this will be done with code like this:
>> 
>> mac:
>>         movsx   rax, edx
>>         movsx   rsi, esi
>>         imul    rsi, rax
>>         lea     rax, [rsi+rdi]
>>         rets

It's more likely that real-world code will use the FMA
(Fused multiply and accumulate) instruction to get the correct rounding.

https://en.wikipedia.org/wiki/FMA_instruction_set

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

#127446

On Wednesday, March 7, 2018 at 11:42:35 AM UTC-6, Scott Lurndal wrote:
> It's more likely that real-world code will use the FMA
> (Fused multiply and accumulate) instruction to get the correct rounding.
> 
> https://en.wikipedia.org/wiki/FMA_instruction_set

For code using floating point, sure.  For integer operations, probably not.
Floating-point hardware is getting cheap enough that a lot of code uses it
for operations that could have been done with integer math, but integer
math can be useful in cost-sensitive applications.  My original example
was intended to do an integer multiply-accumulate on a sequence of 16-bit
values, with the result going into a longer type so as to render rounding
irrelevant.

BTW, I've not heard of an FMA instruction that would be equivalent to

    double muladd(float x, float y, double z) { return ((double)x*y)+z; }

In many cases, a dot product will be performed on coefficients that can
be stored with acceptable precision using "float", but performing rounding
after each addition will cause a progressive loss of accuracy; a 256-entry
dot product of floats end up with a result that's off by almost 128ulp.
Such loss could be mitigated by pairing items to be added, then adding
the sums of pairs, etc. but a compiler would be hard-pressed to vectorize
code that performed calculations in such a fashion.

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

#127382

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]

#127386

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]

#127389

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]

#127451

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]

#127465

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]

#127468

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]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web