>> However, I think it is good practice to include the "volatile". It is
>> also important to note that compiler can re-order and re-arrange
>> assembly instructions and other code, within certain limitations.
>
> GCC has a pragma that allows you to selectively disable optimization. I
> use it when crafting code that I need to take total control of execution
> (for example, bit banging).
>
> JJS
-Os works pretty well even there. I have plenty of bit-banging on GCC,
using AVR's and different ARM's, without a hitch.
Of course, in critical parts, it is common sense to read the generated
assembly listings.
--
-TV
Reply by David Brown●June 18, 20182018-06-18
On 18/06/18 18:39, John Speth wrote:
>> However, I think it is good practice to include the "volatile". It is
>> also important to note that compiler can re-order and re-arrange
>> assembly instructions and other code, within certain limitations.
>
> GCC has a pragma that allows you to selectively disable optimization. I
> use it when crafting code that I need to take total control of execution
> (for example, bit banging).
>
That is certainly possible. However, it is almost always possible to
write code in a way that is correct regardless of the optimisation
choices, with barriers, dependency control, volatile, attributes, etc.
But correctness is the most important factor, and not everyone is
interested in learning the details of how to handle barriers and
dependencies in gcc - a couple of pragmas to limit optimisation may be a
simple and effective strategy.
Reply by John Speth●June 18, 20182018-06-18
> However, I think it is good practice to include the "volatile". It is
> also important to note that compiler can re-order and re-arrange
> assembly instructions and other code, within certain limitations.
GCC has a pragma that allows you to selectively disable optimization. I
use it when crafting code that I need to take total control of execution
(for example, bit banging).
JJS
Reply by ●June 18, 20182018-06-18
On Mon, 18 Jun 2018 09:07:02 +0200, Johann Klammer
<klammerj@NOSPAM.a1.net> wrote:
>On 06/17/2018 07:29 PM, David Brown wrote:
>>
>> Why do you want an alternative to gas? It does pretty much everything you could want from an assembler, as far as I know.
>>
>> It is a long time since I have seen much need to write whole programs in assembly - C (or even C++) is just so much more efficient when your task is to write correct, readable, maintainable code in a reasonable amount of development time.
>>
>gas can't handle labels inside macros,
If that would be the case (which is in doubt based on other replies),
you can always pass a unique label manually on the macro call line
even on the most brain dead assembler that supports macros.
.
>and gcc had disappeared nops
>the last time I wrote sthg timing critical.
>So I'm looking for alternatives now and then.
>(I just need a macro assembler)
>
>At closer inspection it seems that avra only supports
>absolute addresses... so using it together with ld won't work...
>would have to rewrite parts of it for that...
>
>The weird thing is that they have an example in their
>repository which consists of multiple asm files, but I
>can't tell how that would be compiled down to a single hex,
>as it basically outputs 1 hex for 1 asm.
Separate assembly into multiple relocatable objects and then
linking/locating into an absolute file was a great thing with slow
Intellecs and Excorcisers with floppy drives.
These days all assembly program development is done by cross assembly
on a fast PC, in which assembling a whole project into a single
absolute file is fast, even after fixing only one assembly line. So
just assembly all source files at once into an absolute file.
Reply by Grant Edwards●June 18, 20182018-06-18
On 2018-06-18, David Brown <david.brown@hesbynett.no> wrote:
> But I would also recommend forgetting about gas - and forgetting about
> writing code in assembly. You need a really god reason to be writing
> anything more than tiny snippets in assembly these days.
What he said.
Many years ago, I did some profiling of an ARM7 project that was
written in C using GCC 3.something. The application was spening a
significant portion of its time in the BSD network stack's IP checksum
function (which was written in standard C).
No problem, thought I, as I wrote my own IP checksum function in ARM7
assembly. It was slower than the C function. After several solid
days of work (including a hint from somebody about some pretty obscure
ARM7 instruction features), I managed to come up with an IP checksum
function that was noticably faster than the standard C one.
A couple years later, there was a update to both the network stack and
GCC. I re-ran the comparisons, and my carefully crafted assembly
language was now slightly slower than the network stack's C version.
--
Grant Edwards grant.b.edwards Yow! My mind is a potato
at field ...
gmail.com
Reply by Przemek Klosowski●June 18, 20182018-06-18
On Mon, 18 Jun 2018 10:18:09 +0300, Tauno Voipio wrote:
> On 06/18/2018 09:27 AM, David Brown wrote:
>>
>> Yes it can.
>>
>> Use ".altmacro" instead of ".macro", and you can make local names and
>> labels using "LOCAL name". You can also use numeric local labels, or
>> \@ for a macro invocation number.
>>
> LOCAL seems to work... I remember having problems
> with the numeric labels before...nesting?
>
If you have nested macros in your assembly with multiple loops, you are
probably over-complicating things.
> It's maybe best to just forget about avra then...
>
I'd say so, yes.
But I would also recommend forgetting about gas - and forgetting about
writing code in assembly. You need a really god reason to be writing
anything more than tiny snippets in assembly these days.
Reply by David Brown●June 18, 20182018-06-18
On 18/06/18 09:18, Tauno Voipio wrote:
> On 18.6.18 10:07, Johann Klammer wrote:
>> On 06/17/2018 07:29 PM, David Brown wrote:
>>>
>>> Why do you want an alternative to gas? It does pretty much
>>> everything you could want from an assembler, as far as I know.
>>>
>>> It is a long time since I have seen much need to write whole programs
>>> in assembly - C (or even C++) is just so much more efficient when
>>> your task is to write correct, readable, maintainable code in a
>>> reasonable amount of development time.
>>>
>> gas can't handle labels inside macros, and gcc had disappeared nops
>> the last time I wrote sthg timing critical.
>> So I'm looking for alternatives now and then.
>> (I just need a macro assembler)
>>
>> At closer inspection it seems that avra only supports
>> absolute addresses... so using it together with ld won't work...
>> would have to rewrite parts of it for that...
>>
>> The weird thing is that they have an example in their
>> repository which consists of multiple asm files, but I
>> can't tell how that would be compiled down to a single hex,
>> as it basically outputs 1 hex for 1 asm.
>>
>
> Did you declare the gcc nop as volatile?
>
> There are instructions in the manual stating that.
>
An extended syntax inline asm statement doesn't actually need to be
declared volatile if there is no output, so this is okay:
asm ("nop" :::)
However, I think it is good practice to include the "volatile". It is
also important to note that compiler can re-order and re-arrange
assembly instructions and other code, within certain limitations.
If the OP can post the code he was trying to use, I am confident that we
can help him out with the correct syntax. (Of course, he could just
read the manual - the avr-libc documentation has a lot of useful
information. But sometimes it can be hard to digest.)
Reply by Johann Klammer●June 18, 20182018-06-18
On 06/18/2018 09:27 AM, David Brown wrote:
>
> Yes it can.
>
> Use ".altmacro" instead of ".macro", and you can make local names and
> labels using "LOCAL name". You can also use numeric local labels, or
> \@ for a macro invocation number.
>
LOCAL seems to work... I remember having problems
with the numeric labels before...nesting?
It's maybe best to just forget about avra then...
Reply by ●June 18, 20182018-06-18
Johann Klammer wrote:
>
> [...]
> The weird thing is that they have an example in their
> repository which consists of multiple asm files, but I
> can't tell how that would be compiled down to a single hex,
> as it basically outputs 1 hex for 1 asm.
Are you sure that the files are not simply included and the result then
processed in a single assembler run?