Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26717
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Portable Assembly |
| Date | 2017-06-02 13:27 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <ogrht1$5e7$1@dont-email.me> (permalink) |
| References | (6 earlier) <oghk0h$hhr$1@dont-email.me> <ogi2mg$6lf$1@dont-email.me> <ogjt9d$skn$1@dont-email.me> <ogm2kl$hqj$1@dont-email.me> <ogpqhh$ahc$1@dont-email.me> |
On 01/06/17 21:43, Dimiter_Popoff wrote:
> On 31.5.2017 г. 12:36, David Brown wrote:
>> On 30/05/17 15:53, Dimiter_Popoff wrote:
>>> On 30.5.2017 г. 00:13, David Brown wrote:
>>>> On 29/05/17 19:02, Dimiter_Popoff wrote:
>>>>> On 29.5.2017 г. 16:06, David Brown wrote:
>>>>
>>>> <snipped some interesting stuff about VPA>
>>>>
>>>>>
>>>>>> Some time it might be fun to look at some example functions, compiled
>>>>>> for either the 68K or the PPC (or, better still, both) and compare
>>>>>> both
>>>>>> the source code and the generated object code to modern C and
>>>>>> modern C
>>>>>> compilers. (Noting that the state of C compilers has changed a great
>>>>>> deal since you started making VLA.)
>>>>>
>>>>> Yes, I would also be curious to see that. Not just a function - as it
>>>>> will likely have been written in assembly by the compiler author - but
>>>>> some sort of standard thing, say a base64 encoder/decoder or some
>>>>> vnc server thing etc. (the vnc server under dps is about 8 kilobytes,
>>>>> just looked at it. Does one type of compression (RRE misused as
>>>>> RLE) and
>>>>> raw).
>>>>>
>>>>
>>>> To be practical, it /should/ be a function - or no more than a few
>>>> functions. (I don't know why you think functions might be written in
>>>> assembly by the compiler author - the compiler author is only going to
>>>> provide compiler-assist functions such as division routines, floating
>>>> point emulation, etc.) And it should be something that has a clear
>>>> algorithm, so no one can "cheat" by using a better algorithm for the
>>>> job.
>>>>
>>>>
>>>
>>> I am pretty sure I have seen - or read about - compiler generated
>>> code where the compiler detects what you want to do and inserts
>>> some assembly prewritten piece of code. Was something about CRC
>>> or about tcp checksum, not sure - and it was someone who said that,
>>> I don't know it from direct experience.
>>
>> A compiler sees the source code you write, and generates object code
>> that does that job. It be smart about it, but it will not insert
>> "pre-written assembly code".
> Code generation in compilers is usually
>> defined with some sort of templates (such a pattern for reading data at
>> a register plus offset, or a pattern for doing a shift by a fixed size,
>> etc.). They are not "pre-written assembly", in that many of the details
>> are determined at generation time, such as registers, instruction
>> interleaving, etc.
>>
>> The nearest you get to pre-written code from the compiler is in the
>> compiler support libraries. For example, if the target does not support
>> division instructions, or floating point, then the compiler will supply
>> routines as needed. These /might/ be written in assembly - but often
>> they are written in C.
>>
>>
>> A compiler /will/ detect patterns in your C code and use that to
>> generate object code rather than doing a "direct translation". The
>> types of patterns it can detect varies - it is one of the things that
>> differentiates between compilers.
>
> We are referring to the same thing under different names - again.
OK. I think your naming and description is odd, but I am glad to see we
are getting a better understanding of what the other is saying.
> At the end of the day everything the compiler generates is written
> in plain assembly, it must be executable by the CPU.
> Under "prewritten" I mean some sort of template which gets filled
> with addresses etc. thing before committing.
I think of "prewritten" as referring to larger chunks of assembly code,
with much more concrete choices of values, registers, scheduling, etc.
You described the "prewritten" code as being easily recognisable - in
reality, the majority of the code from modern compilers is generated
from very small templates with great variability. And on a processor
like the PPC, these will be intertwined with each other according to the
best scheduling for the chip.
As an example, if we have the function:
int foo0(int * p) {
int a = *p * *p;
return a;
}
The template for reading "*p" generates
lmz 3, 0(3)
(Register r3 is used for the first parameter in the PPC eabi. It is
also used for the return value from a function, which is why it may seem
"over used" in the examples here. In bigger code, and when the compiler
can inline functions, it will be more flexible about register choices.
I don't know whether you follow the standard PPC eabi in your tools.)
Multiplication is another template:
mullw 3, 3, 3
As is function exit, in this case just:
blr
I find it very strange to consider these as "pre-written assembly".
And if the function is more complex, the intertwining causes more
mixups, making it less "pre-written":
int foo1(int * p, int * q) {
int a = *p * *p;
int b = *q * *q;
return a + b;
}
foo1:
lwz 9,0(3)
lwz 10,0(4)
mullw 9,9,9
mullw 3,10,10
add 3,9,3
blr
> To what lengths the compiler writers go to make common cases look
> good know only the writers themselves, my memory is vague but I
> do think the guy who said that a few years ago knew what he was
> talking about.
Well, it is known to the compiler writers and to users who look at the
generated code! Certainly there is plenty of variation between tools,
with more advanced compilers working harder at this sort of thing.
Command line switches with choices of optimisation levels can also make
a big difference.
How much experience do you have of using C compilers, and studying their
output?
>
>> .. A classic example for the PPC would be:
>>
>> #include <stdint.h>
>>
>> uint32_t reverseLoad(uint32_t * p) {
>> uint32_t x = *p;
>> return ((x & 0xff000000) >> 24)
>> | ((x & 0x00ff0000) >> 8)
>> | ((x & 0x0000ff00) << 8)
>> | ((x & 0x000000ff) << 24);
>> }
>>
<skipping the details>
>> But if we ask for smarter optimisation, with -O2, we get:
>>
>> reverseLoad:
>> lwbrx 3,0,3
>> blr
>>
>> This is, of course, optimal. (Even the function call overhead will be
>> eliminated if the compiler can do so when the function is used.)
>
> Above all this is a good example how limiting the high level language
> is. Just look at the source and then at the final result.
No, that is a good example of how smart the compiler is (or can be)
about generating optimal code from the source.
You may in addition view this as a limitation of the C language, which
has no direct way to specify a "bit reversed pointer". That is fair
enough. However, it is not really any harder than defining a function
like this, and then using it. For situations where the compiler can't
generate ideal code, and it is particularly useful to get such optimal
assembly, it is also possible to write a simple little inline assembly
function - it is not really any harder than writing the same thing in
"normal" assembly.
Another option (for newer gcc) is to define the endianness of a struct.
Then you can access the fields directly, and the loads and stores will
be reversed as needed.
typedef struct __attribute__((scalar_storage_order ("little-endian"))) {
uint32_t x;
} le32_t;
uint32_t reverseLoad2(le32_t * p) {
return p->x;
}
reverseLoad2:
lwbrx 3,0,3
blr
So the high level language gives you a number of options, with specific
tools giving more options, and the implementation gives you efficient
object code in the end. You might need to define a function or macro
yourself, but that is a one-time job.
>
> You will get *exactly* the same result (- the return) with no
> optimization in vpa from the line:
>
> mover.l (source),r3
When you say "no optimisation" here, does that mean that VPA supports
some kinds of optimisations?
>
> Logic optimization is more or less a kindergarten exercise. If you need
> logic optimization you don't know what you are doing anyway so the
> compiler won't be able to help much, no matter how good.
What do you mean by "logic optimisation" ? It is normal for a good
compiler to do a variety of strength reduction and other re-arrangements
of code to give you something with the same result, but more efficient
execution. And it is a /good/ thing that the compiler does that - it
means you can write your source code in the clearest and most
maintainable fashion, and let the compiler generate better code.
For example, if you have a simple division by a constant:
uint32_t divX(uint32_t a) {
return a / 5;
}
The direct translation of this would be:
divX:
lis 4,5
divwu 3,3,4
blr
But a compiler can do better:
divX: // divide by 5
lis 9,0xcccc
ori 9,9,52429
mulhwu 3,3,9
srwi 3,3,2
blr
Such optimisation is certainly not a "kindergarten exercise", and doing
it by hand is hardly a maintainable or flexible solution. Changing the
denominator to 7 means significant changes:
divX: // divide by 7
lis 9,0x2492
ori 9,9,18725
mulhwu 9,3,9
subf 3,9,3
srwi 3,3,1
add 3,9,3
srwi 3,3,2
blr
>
> Of course if you stick by a phrase book at source level - as is the case
> with *any* high level language - you will need plenty of optimization,
> like your example demonstrates.
I still don't know what you mean with "phrase book" here.
> I bet it will will be good only in demo
> cases like yours and much less useful in real life,
Nonsense. The benefits of using a higher level language and a compiler
get more noticeable with larger code, as the compiler has no problem
tracking register usage, instruction scheduling, etc., across large
pieces of code - unlike a human. And it has no problem re-creating code
in different ways when small details change in the source (such as the
divide by 5 and divide by 7 examples).
> so the only benefit
> of writing this in C is the source length, 10+ times the necessary (I
> counted it and I included a return line in the count, 238 vs. 23 bytes).
You have this completely backwards. If I write a simple example like
this, in a manner that is compilable code, then it is going to take
longer in high-level source code. But that is the effect of giving that
function definition. In use, writing "reverseLoad" does not take
significantly more characters than "mover" - and with everything else
around, the C code will be much shorter. And this was a case picked
specifically to show how some long patterns in C code can be handled by
a compiler to generate optimal short assembly sequences.
The division example shows the opposite - in C, I write "a / 7", while
in assembly you have to write 7 lines (excluding labels and blr). And
the C code there is nicer in every way.
> While 10 times more typing may seem no serious issue to many 10 times
> higher chance to insert an error is no laughing matter, and 10 times
> more obscurity just because of that is a productivity killer.
In real code, the C source will be 10 times shorter than the assembly.
And if the assembly has enough comments to make it clear, there is
another order of magnitude difference.
>
>>> But if the compiler does this it will be obvious enough.
>>
>> If you had some examples or references, it would be easier to see what
>> you mean.
>>
>>>
>>> Anyway, a function would do - if complex and long enough to
>>> be close to real life, i.e. a few hundred lines.
>>
>> A function that is a few hundred lines of source code is /not/ real life
>> - it is broken code. Surely in VLA you divide your code into functions
>> of manageable size, rather than single massive functions?
>
> I meant "function" not the in C subroutine kind of sense, I meant it
> more as "functionality", i.e. some code doing some job. How it split
> into pieces etc. will depend on many factors, language, programmer
> style etc., not relevant to this discussion.
OK.
But again, it has to be a specific clearly defined and limited
functionality. "Write a VNC server" is not a specification - that would
take at least many dozens of pages of specifications, not including the
details of the interfacing to the network stack, the types of library
functions available, the API available to client programs that will
"draw" on the server, etc.
>
>>>
>>> But I don't see why not compare written stuff, I just checked
>>> again on that vnc server for dps - not 8k, closer to 11k (the 8k
>>> I saw was a half-baked version, no keyboard tables inside it etc.;
>>> the complete version also includes a screen mask to allow it
>>> to ignore mouse clicks at certain areas, that sort of thing).
>>> Add to it some menu (it is command line option driven only),
>>> a much more complex menu than windows and android RealVNC has
>>> I have and it adds up to 25k.
>>> Compare this to the 350k exe for windows or to the 4M for Android
>>> (and the android does only raw...) and the picture is clear enough
>>> I think.
>>>
>>
>> A VNC server is completely useless for such a test. It is far too
>> complex, with far too much variation in implementation and features, too
>> many external dependencies on an OS or other software (such as for
>> networking), and far too big for anyone to bother with such a comparison.
>
> Actually I think a comparison between two pieces of code doing the same
> thing is quite telling when the difference is in the orders of
> magnitude, as in this case.
No, it is not. The code is not comparable in any way, and does not do
the same thing except in a very superficial sense. It's like comparing
a small car with a train - both can transport you around, but they are
very different things, each with their advantages and disadvantages.
If you want to compare your VNC server for DPS written in VPA to a VNC
server written in C, then you would need to give /exact/ specifications
of all the features of your VNC server, and exact details of how it
interfaces with everything else in the DPS system, and have someone
write a VNC server in C for DPS that follows those same specifications.
That would be no small feat - indeed, it would totally impossible
unless you wanted to do it yourself.
The nearest existing comparison I can think of would be the eCos VNC
server, written in C. I can't say how it compares in features with your
server, but it has approximately 2100 lines of code, written in a wide
style. Since I have no idea about how interfacing with DPS compares
with interfacing with eCos (I don't know either system), I have no idea
if that is a useful comparison or not.
> Writing small benchmarking toy sort of stuff is a waste of time, I am
> interested in end results.
>
>>
>> You specifically need something /small/.
>
> No, something "small" is kind of kindergarten exercise again, it can
> only be good enough to fool someone into believing this or that.
> It is end results which count.
>
Then we will all remain in ignorance about whether VPA is useful or not,
in comparison to developing in C.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Portable Assembly rickman <gnuarm@gmail.com> - 2017-05-27 15:39 -0400
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-27 21:05 +0000
Re: Portable Assembly Mel Wilson <mwilson@the-wire.com> - 2017-05-27 21:29 +0000
Re: Portable Assembly upsidedown@downunder.com - 2017-05-28 00:36 +0300
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-27 21:56 +0000
Re: Portable Assembly Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-05-28 14:36 +0200
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 09:53 +0200
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-05-27 16:17 -0500
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 00:31 +0300
Re: Portable Assembly Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-05-27 22:52 +0100
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-27 21:58 +0000
Re: Portable Assembly upsidedown@downunder.com - 2017-05-28 07:37 +0300
Re: Portable Assembly rickman <gnuarm@gmail.com> - 2017-05-28 01:28 -0400
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-28 07:33 +0100
Re: Portable Assembly rickman <gnuarm@gmail.com> - 2017-05-28 03:22 -0400
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-28 08:49 +0100
Re: Portable Assembly upsidedown@downunder.com - 2017-05-28 15:03 +0300
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-05-28 12:26 +0300
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 01:04 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 10:43 +0200
Re: Portable Assembly Anssi Saari <as@sci.fi> - 2017-05-31 10:19 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-31 01:49 -0700
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-05-31 15:56 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 02:33 -0700
Re: Portable Assembly upsidedown@downunder.com - 2017-05-29 23:46 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 13:54 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 15:52 -0700
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 02:14 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 17:14 -0700
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 03:38 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 18:42 -0700
Re: Portable Assembly Stefan Reuther <stefan.news@arcor.de> - 2017-05-28 18:45 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 20:47 +0300
Re: Portable Assembly Stefan Reuther <stefan.news@arcor.de> - 2017-05-29 18:43 +0200
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 10:23 -0700
Re: Portable Assembly "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-05-30 16:31 +0200
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-29 01:59 +0000
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-29 05:21 +0300
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-05-28 22:04 -0500
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 02:57 -0700
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 11:00 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-29 15:08 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 15:06 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-29 20:02 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 23:13 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-30 16:53 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-31 11:36 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-01 22:43 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-02 13:27 +0200
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-29 13:48 +0000
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 15:46 -0700
Re: Portable Assembly Tim Wescott <tim@seemywebsite.really> - 2017-05-28 23:59 -0500
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 00:23 +0300
Re: Portable Assembly jim.brakefield@ieee.org - 2017-05-27 16:54 -0700
Re: Portable Assembly Walter Banks <walter@bytecraft.com> - 2017-05-29 17:23 -0400
Re: Portable Assembly "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-06-02 17:03 +0200
Re: Portable Assembly Mike Perkins <spam@spam.com> - 2017-06-05 15:39 +0100
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-05 18:10 +0200
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-05 09:10 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-06 00:24 -0400
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-06 11:05 +0200
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-06 07:03 -0700
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-06 16:58 +0200
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-06-06 21:26 +0300
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-06 16:42 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-06 23:16 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-08 06:38 -0400
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-08 15:58 +0300
Re: Portable Assembly upsidedown@downunder.com - 2017-06-08 21:34 +0300
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-06-10 15:27 -0500
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-06-10 15:23 -0500
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-08 14:50 +0100
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-06-08 17:38 +0300
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-08 16:37 +0100
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-09 14:14 -0400
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-09 22:25 +0100
Re: Portable Assembly Clifford Heath <no.spam@please.net> - 2017-06-10 09:54 +1000
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-09 00:06 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-09 22:14 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-09 22:50 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-10 21:01 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-11 00:39 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-12 23:27 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-12 22:42 -0700
Re: Portable Assembly Ed Prochak <edprochak@gmail.com> - 2017-06-13 14:24 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-13 21:57 -0700
Re: Portable Assembly Reinhardt Behm <rbehm@hushmail.com> - 2017-06-14 13:26 +0800
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-13 23:58 -0700
Re: Portable Assembly Ed Prochak <edprochak@gmail.com> - 2017-06-19 06:48 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-19 16:45 -0700
Re: Portable Assembly Ed Prochak <edprochak@gmail.com> - 2017-06-20 15:07 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-21 07:37 -0700
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-07 09:20 +0200
Re: Portable Assembly Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-06-07 00:30 +0300
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-07 02:02 -0400
csiph-web