Simple Maple-Arduino speed comparison reveals compiler bugs

LeafLabs Garden » Support » Maple IDE Support

Simple Maple-Arduino speed comparison reveals compiler bugs

(19 posts) (6 voices)

Started 5 years ago by StephenFromNYC
Latest reply from gbulmer

12 Next »

StephenFromNYC
Moderator

Wednesday September 1, 2010

Hello-

I am looking forward to Maple-IDE release 0.0.7 and I am happy to help by searching for bugs in the code and by improving the documentation.

I decided to write simple code to compare the looping speed of the Maple and the Arduino Duemilanove (ATmega 328 chip).

I used the Maple-IDE 0.0.6 and the slightly outdated Arduino-IDE 017. My code uses simple nested For-Next loops (with and without If statements).

The results in the comparison are shown below. I did not continue with the timings once it took more than 10 seconds to complete each set of nested loops. I observed mainly expected behavior (the Maple is 4X-5X faster than the Arduino), but also a few surprises.

The speed comparison is not exact, because the code was uploaded to Maple RAM, but to Arduino FLASH memory. I am having problems with uploads to my Maple FLASH memory, and even using the "perpetual bootloader mode" does not work

Using seven "empty" nested loops both compilers optimize the code. I did not look at the object code, but I suspect both compilers simply omitted the loop code, resulting in fast 0 millisecond (0 ms) execution times.

Then I reduced the number of loops to four and in the innermost loop I added an "if" statement which prints a message on the last iteration of the loops before the loops terminate. The Maple executes the code 4X-5X faster than the Arduino Duemilanove.

Then I tried something unorthodox. I removed the innermost comparison and print statements, but I changed the "limit" variable from type int to type float. Normally, this would not be done, because float operations require more cpu cycles. Both the Maple and Arduino compilers do not optimize this code. Even though the nested loops are "empty" the amount of time to execute the loops is significantly greater than 0 ms and increases as the limit variable increases.

Is this something which should be brought to the attention of both compiler authors (avr-gcc and arm-non-eabi-gcc)? I do not know if this "bug" affects the efficiency of other functions.

Then I changed the "limit" variable to type long (both signed and unsigned) which might be done in real code. With empty loops, the Maple compiler behaves correctly for all values tested, but the Arduino compiler misbehaves when the "limit" variable is greater than 32767. The last message I see is "Start loops". I did not determine if the code crashes before the first call to millis() or if the code crashes in the nested loops.

I might expect code to misbehave if longs on the Arduino had an upper limit of 32767. However, the Arduino documentation describes a range of -2,147,483,648 to 2,147,483,647 for longs and 0 to 4,294,967,295 for unsigned longs.

What other unexpected behavior are other users finding? Note: I did not try to change the type of the "counterN" variables from int to float or long. I do not know if this will affect how the code is compiled.

Thanks!

Stephen from NYC

<start of code>

/*

Compiler Optimization Loop Bug Test

This code is currently configured to use four nested loops.
The innermost loops does not do any comparisons and does not print.

The speed comparison is not exact, because the code was uploaded to Maple RAM, but to Arduino FLASH memory.

Created 31 August 2010, last updated 01 September 2010
By leaflabs.com forums member "Stephen from NYC"

This code is released under a Creative Commons Attribution-Share Alike 3.0 license.

*/

void setup() {

/* Serial.begin() is not needed by the Maple, but is needed by the Arduino */

// Serial.begin(9600);
}

void loop() {

// SEVEN loops (withOUT comparison and call to inner loop println function)
// Maple R3 (IDE 0.0.6): int limit= 100 ( 0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): int limit= 1000 ( 0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): int limit= 10000 ( 0 ms); Arduino (IDE 017): 0 ms

// FOUR loops (with comparison and call to inner loop println function)
// Maple R3 (IDE 0.0.6): int limit= 10 ( 3 ms); Arduino (IDE 017): 28 ms
// Maple R3 (IDE 0.0.6): int limit= 20 ( 29 ms); Arduino (IDE 017): 137 ms
// Maple R3 (IDE 0.0.6): int limit= 30 ( 140 ms); Arduino (IDE 017): 601 ms
// Maple R3 (IDE 0.0.6): int limit= 40 ( 438 ms); Arduino (IDE 017): 1840 ms
// Maple R3 (IDE 0.0.6): int limit= 60 ( 2197 ms); Arduino (IDE 017): 9510 ms
// Maple R3 (IDE 0.0.6): int limit= 70 ( 4062 ms); Arduino (IDE 017): 16890 ms
// Maple R3 (IDE 0.0.6): int limit= 80 ( 6197 ms)
// Maple R3 (IDE 0.0.6): int limit= 100 (16851 ms)

// THREE loops (withOUT comparison and call to inner loop println function)
// Maple R3 (IDE 0.0.6): float limit= 50 ( 11 ms); Arduino (IDE 017): 49 ms
// Maple R3 (IDE 0.0.6): float limit= 70 ( 29 ms); Arduino (IDE 017): 133 ms
// Maple R3 (IDE 0.0.6): float limit= 80 ( 43 ms); Arduino (IDE 017): 198 ms
// Maple R3 (IDE 0.0.6): float limit= 100 ( 84 ms); Arduino (IDE 017): 384 ms
// Maple R3 (IDE 0.0.6): float limit= 200 ( 671 ms); Arduino (IDE 017): 3048 ms
// Maple R3 (IDE 0.0.6): float limit= 300 ( 2266 ms); Arduino (IDE 017): 11963 ms
// Maple R3 (IDE 0.0.6): float limit= 400 ( 5365 ms)
// Maple R3 (IDE 0.0.6): float limit= 500 (10471 ms)

// THREE loops (with comparison and call to inner loop println function)
// Maple R3 (IDE 0.0.6): float limit= 10 ( 3 ms); Arduino (IDE 017): 30 ms
// Maple R3 (IDE 0.0.6): float limit= 20 ( 19 ms); Arduino (IDE 017): 95 ms
// Maple R3 (IDE 0.0.6): float limit= 30 ( 61 ms); Arduino (IDE 017): 262 ms
// Maple R3 (IDE 0.0.6): float limit= 40 ( 143 ms); Arduino (IDE 017): 578 ms
// Maple R3 (IDE 0.0.6): float limit= 100 ( 2184 ms); Arduino (IDE 017): 8115 ms
// Maple R3 (IDE 0.0.6): float limit= 120 ( 3766 ms); Arduino (IDE 017): 13848 ms
// Maple R3 (IDE 0.0.6): float limit= 200 (17365 ms)

// FOUR loops (withOUT comparison and call to inner loop println function)
// Maple R3 (IDE 0.0.6): unsigned long limit= 1000 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): unsigned long limit= 30000 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): unsigned long limit= 32767 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): unsigned long limit= 32768 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): unsigned long limit= 50000 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): unsigned long limit= 100000 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): unsigned long limit= 1000000 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): unsigned long limit= 10000000 (0 ms); Arduino (IDE 017): (see only "Start loops")

// FOUR loops (withOUT comparison and call to inner loop println function)
// Maple R3 (IDE 0.0.6): long limit= 1000 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): long limit= 16384 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): long limit= 16385 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): long limit= 32767 (0 ms); Arduino (IDE 017): 0 ms
// Maple R3 (IDE 0.0.6): long limit= 32768 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): long limit= 40000 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): long limit= 100000 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): long limit= 1000000 (0 ms); Arduino (IDE 017): (see only "Start loops")
// Maple R3 (IDE 0.0.6): long limit= 10000000 (0 ms); Arduino (IDE 017): (see only "Start loops")

int limit=40;

int counter1=0;
int counter2=0;
int counter3=0;
int counter4=0;
int counter5=0;
int counter6=0;
int counter7=0;

unsigned long start=0;
unsigned long stop=0;

SerialUSB.println("Start loops");

// Serial.println("Start loops");

start=millis();

for (counter1=0; counter1 < limit; counter1++)
{
for (counter2=0; counter2 < limit; counter2++)
{
for (counter3=0; counter3 < limit; counter3++)
{
for (counter4=0; counter4 < limit; counter4++)
{

/* inner loops 5/6/7 */
/*
for (counter5=0; counter5 < limit; counter5++)
{
for (counter6=0; counter6 < limit; counter6++)
{
for (counter7=0; counter7 < limit; counter7++)
{
*/

/* the compare and print line needs to be edited for loop number and also Arduino/Maple println() differences */
if ((counter1==(limit-1)) && (counter2==(limit-1)) && (counter3==(limit-1)) && (counter4==(limit-1)) /* && (counter5==(limit-1)) && (counter6==(limit-1)) && (counter7==(limit-1)) */ ) SerialUSB.println("Inner loop finished");

/* closing parentheses for inner loops 5/6/7 */
/*
}
}
}
*/

}
}
}
}

stop=millis();

/* Code for Maple */

SerialUSB.println("Stop loops");
SerialUSB.print("elapsed time= ");
SerialUSB.print(stop-start);
SerialUSB.print(" ms (for limit=");
SerialUSB.print(limit);
SerialUSB.println(")\n");

/* Code for Arduino */

/*
Serial.println("Stop loops");
Serial.print("elapsed time= ");
Serial.print(stop-start);
Serial.print(" ms (for limit=");
Serial.print(limit);
Serial.println(")\n");
*/

}

Posted 5 years ago #
gbulmer
Moderator
I think the when you say

Then I changed the "limit" variable to type long (both signed and unsigned) which might be done in real code. With empty loops, the Maple compiler behaves correctly for all values tested, but the Arduino compiler misbehaves when the "limit" variable is greater than 32767. The last message I see is "Start loops". I did not determine if the code crashes before the first call to millis() or if the code crashes in the nested loops.

The problem is the declarations:
```
int counter1=0;
int counter2=0;
int counter3=0;
int counter4=0;
int counter5=0;
int counter6=0;
int counter7=0;
```
I believe on the Maple, a long and an int are both 32 bits. So everything works fine.

But on the Arduino long is 32 bits, and int is only 16 bits (representing -32768 to +32767).
So when 'long limit = 100000;' it is impossible for 'int counter4=0;' to ever get bigger than 32767, so it will be smaller than limit forever.
So I believe the code doesn't crash, it is running into the inner loop, but can never exit the for loop because the condition
'counter4 < limit' is always true.

The definitions of all the counter0 to counter7 need to be long too, then it should work, and show the cost of 32 bit arithmetic on Arduino.

My theory anyway :-)
Posted 5 years ago #
leaflabsandy
Member

32 bit Maple 72 Mhz
8 bit Arduino 16 Mhz

72/16 = 4.5

Quote: "The Maple executes the code 4X-5X faster than the Arduino Duemilanove"

Reply: Hmmm

Posted 5 years ago #
CarlO
Member

Hey StephenFromNYC,

Interesting results. The Maple is much faster than expected on the loops that print. I think some of the speed increase you are seeing with the loops that print may be due to the high speed USB hardware on the Maple, instead of the Serial to USB on the Arduino which is limited by the baud rate between the Atmega and the FTDI USB chip.

I believe that on the Maple (STM32) the memory access speed should be the same for Flash and SRAM, so that should not change your results.

Where the Maple should really shine over the Arduino is in handling 32 bit values and floats. Handling 32 bit numbers on the 8 bit Arudino takes some gymnastics. So for simple applications, 4X-5X is what you would expect. For doing any real computation, the Maple should run circles around the 8bit Arduino.

Comparing a float with an int is a bit tricky due to the binary representation of the decimal float and potential rounding errors. For example if the int contains 1000 and the float contains 1000.001 or 999.9999 are they the same or not? For most practical purposes (i.e. your loop test) they are the same but the compiler has no way to really know what you are trying to do. I believe that the compiler will "promote" the int to a float to do the comparison. To really do the comparison correctly, you need to round the float(s) before comparing so that the comparison doesn't come down to the least significant bit. This may be the reason that they don't try to optimize your loop.

I'm not sure I see an actual "Bug" here although it may be true that the optimizations aren't perfect and may not be ideal for the processors we are using. I believe that the compilers are both offshoots of the GCC and G++ projects and are both open source, so if you are really concerned about it you could try reporting what you are seeing or just dig into the issue yourself.

CarlO

Posted 5 years ago #
poslathian
LeafLabs

cool!

In terms of performance, we havnt really scratched the surface. Sure the clock is faster. But the real win comes from DMA, using fast interrupts, and dedicated communication peripheral (i2c,spi, etc). I cant wait to start benchmarking that stuff. Incidentally weve finally started on bringing up the DMA, which allows you to do fancy stuff like copy memory from location A to B in the "background" with wasting cycles (except the cycles needed to dispatch the copy operation through the DMA). This works really nicely for communication, where you can throw a bunch of data into a buffer and the use the DMA to squirrel it all out of a uart/i2c/spi port without actually spending cycles to do that. If anyone has some free cycles, it would be a great help to do some advanced play using those features!

*warning* i2c peripheral is nasty complicated, but the dma is simple.

Posted 5 years ago #
gbulmer
Moderator

CarlO, I think llandy's calculation of 72MHz/16MHz - 4.5 gives an answer in a similar ball park to the relative speed of the Maple and Arduino on the cases where there is a nonzero time.

The theory that the Maple I/O is making a significant difference could be tested by printing a singe character instead of
SerialUSB.println("Inner loop finished"); or its Arduino equivalent,
print one character:
SerialUSB.print("."); or its Arduino equivalent.

The serial output (USART) on the Aduino has one byte of buffering, so this should minimise any differences between the two systems, leaving mostly the difference in for loop speed.

As CarlO wrote, comparing loops using 32-bit long for limit and counters should show up a bigger performance difference than the clock speed alone would account for because the Maple's 32-bit Cortex-M3 (STM32F) can process 32 bit numbers in far fewer instructions than the Arduino's 8-bit ATmega can perform the same operation.

I am actually impressed that the Arduino seems to be slightly faster than the clock speed difference might suggest on integer operations.

The memeory access speed for flash and SRAM on the Maple's STM32F is different. According to document 13587.pdf (from st.com), section "2.3.4 Embedded SRAM" says:
Twenty Kbytes of embedded SRAM accessed (read/write) at CPU clock speed with 0 wait
states.

Whereas document 13902.pdf (also from st.com), section "2.3.3 Embedded Flash memory", page 53 says:
"Note: 1 These options should be used in accordance with the Flash memory access time. The wait states represent the ratio of the SYSCLK (system clock) period to the Flash memory access time:
zero wait state, if 0 < SYSCLK <= 24 MHz
one wait state, if 24 MHz < SYSCLK <= 48 MHz
two wait states, if 48 MHz < SYSCLK <= 72 MHz"
The impact of the wait states is reduced by a prefetch buffer, page 52 says:
"Prefetch buffer (2 x 64-bit blocks): it is enabled after reset; a whole block can be
replaced with a single read from the Flash memory as the size of the block matches the
bandwidth of the Flash memory. Thanks to the prefetch buffer, faster CPU execution is
possible as the CPU fetches one word at a time with the next word readily available in
the prefetch buffer"

So Flash memory may be slower than SRAM, but the estimation of how different is not easy because it depends on the dynamic flow of the program.

I don't know if your theory is correct, but think your explanation for the compilers not optimising the for loops is a good one. I'm happy to buy it. As you say the compiler may know that it can't exactly predict how floating arithmetic works in these situations, and takes the conservative (and guaranteed to be correct) approach of compiling the code as written.

I believe the test shows no evidence of *bugs* in the compiler. I don't believe it is a bug to fail to optimise away code in a program. IMHO, a compiler should always strive to geneate code gives the correct answer (i.e. what the code says), and secondarly try to optimise that code.

I think it would be helpful if the compiler did print a warning to the effect that 'comparing int counter0 to long limit might give unexpected results'. Maybe that warning is off by default as many programs would provoke it.
There are a few gcc warnings which might help:
-Wstrict-overflow
-Wfloat-equal
-Wunsafe-loop-optimizations
-Wtype-limits

I think it would be helpful if every set of tests (e.g. using float or long) used the same set of values for limit so that it is easier to compare results across tests.

HTH

Posted 5 years ago #
CarlO
Member

gbulmer,

That's great info on the access time for Flash, thanks for doing the research on this. I guess ST's claim of 1.25 DMIPS/MHz on the front page of the data sheet only applies to SRAM then? Interesting that they hide this info in a footnote. When I get some time I'll do some tests to see what the difference is in practical application terms. I also discovered that the I/O ports are clocked or latched at a lower rate then the CPU core.

"– 72 MHz maximum frequency,1.25 DMIPS/MHz (Dhrystone 2.1)performance at 0 wait state memory access"

CarlO.

Posted 5 years ago #
poslathian
LeafLabs

Since were talking about performance. The stm32 on maple CAN be overclocked! Obviously, at your own peril! User reports and internal experiments suggest that the probability of brickage from stepping up to 120MHz is minimal, however the digital I/O and many of the peripheral start to get funky, square waves turn to sines, and some comm peripherals just stop functioning. You can overclock via setting the PLL multiplier to higher than 9, you can find where this happens in libmaple, probably in rcc.c

Posted 5 years ago #
poslathian
LeafLabs

Bryan's post on the subject:
http://forums.leaflabs.com/topic.php?id=31#post-114

Posted 5 years ago #
gbulmer
Moderator

"- 72 MHz maximum frequency,1.25 DMIPS/MHz (Dhrystone 2.1)performance at 0 wait state memory access"

Yes, I think there is a bit of "marketing spin" creeping in here, but I don't think it is as bad as it might seem.

There is a prefetch buffer which holds two blocks of 64-bits, 2x8 bytes, of instructions which is read in one read from Flash (Flash memory and the ICode instruction bus is 64-bits wide).
If the CPU were executing only 16-bit instructions (that is 4 instructions/block), in perfect conditions the processor wouldn't wait even if Flash had 3-wait states.
Of course, things are not perfect, but for straightline code, or small loops, it might get quite close.

As you say, the "1.25 DMIPS/MHz" is true for internal RAM, and I believe is true for Flash when the STM32F runs at 24MHz, but that's where the "marketing spin" is misleading. It would be very helpful to have some 'typical' values for a suite of apps run at 48MHz and 72MHz.

AFAIK, all the MCU manufacturers apply this same "marketing spin" when their processor runs faster than flash, not just ARM licensees, but others too.

While on the subject of "marketing spin", I noticed that the ADC only reaches 1M sample/second when the processor is clocked at 56MHz, and drops to a best case of roughly 850K samples/second at 72MHz. The disparity is because the ADC clock can't exceeed 14MHz, and it is derived from the system clock, divided down for the ADC by an integer value.

To be fair, 850K samples/second, on each of two or three ADC's, is so much better than an Arduino's <10k samples/second, I am still extremly happy.

Posted 5 years ago #
gbulmer
Moderator

ST have announced 120MHz STM32 parts:
http://www.st.com/stonline/stappl/cms/press/news/year2010/t2477.htm

If they migrate production of existing parts to the smaller process, overclocking may be more stable.

The improvement comes from moving to a smaller scale process (90nm) which means faster transistors. To make up for the disparity between the processor and Flash, they have an even fancier prefetch mechanism than the existing STM32F's:

To release the processor’s full 150 DMIPS performance at this frequency the accelerator implements an instruction pre-fetch queue and branch cache, enabling program execution from Flash at up to 120MHz with zero wait states.

I assume the key words are "at up to" 120MHz :-)

Marketing, don't ya just love 'em?-)

Posted 5 years ago #
StephenFromNYC
Moderator

September 2, 2010

Hello,

Thanks for all the replies to my bug/benchmark post.

leaflabsandy, yes, based on the faster clock speed I was expecting to see the 72 MHz Maple run faster than a 16 MHz Arduino. I was expecting a speedup of roughly 4.5X (=72/16). I did the simple benchmarking to show myself that the Maple runs similar code faster. Do you remember President Reagan quote regarding nuclear treaties "Trust, but verify". Note LeafLabs development team: using a Pentium III computer the Arduino compiles and loads the code faster than the Maple.

In my post I chose the expression "4X-5X" because the speedup varies on the test. The speedup is not always 4.5X. It is occasionally less than 4X but occasionally greater than 5X. It is possible I copied the results incorrectly, but the general trend is clear. In one test which does not show the benefits of a 32- bit MCU the Arduino requires 4X-5X more time to execute similar code.

gbulmer, thanks for your ideas. When I said (at the end of my post) "Note: I did not try to change the type of the 'counterN' variables from int to float or long. I do not know if this will affect how the code is compiled" I did not think it was the cause of the problem!

CarlO, when I was learning C I remember reading about variable type "promotion". This concept is usually taught in the context of int vs float. In my code, when I changed the limit variable to type long I assumed the int counters would be promoted to float during compilation to type long. If this is not a bug in the compiler(s) I obviously do not understand some subtle property of variable promotion. Maybe I should find my old text and read it again!

Regardless of the type of the variable(s) used in a FOR loop, I assumed any empty loop would be optimized by the compiler. Execution of all empty loops should be 0 milliseconds. I forgot, does infinity times zero equal zero or does the product equal NaN (not a number)? Does the NaN concept have any relevance to compilation of an empty loop?

I do not have the time to contact the avr-gcc compiler project. If you are a contributor to the avr-gcc forums and you think I have uncovered a bug please pass on the information.

I wanted to share my observations, because the LeafLabs development team might be interested in sketches where the Maple behaves in surprising ways.

Thanks!

Stephen from NYC

Posted 5 years ago #
gbulmer
Moderator

CarlO, when I was learning C I remember reading about variable type "promotion". This concept is usually taught in the context of int vs float. In my code, when I changed the limit variable to type long I assumed the int counters would be promoted to float during compilation to type long. If this is not a bug in the compiler(s) I obviously do not understand some subtle property of variable promotion. Maybe I should find my old text and read it again!

C/C++ is very obedient, which can be surprising.

When a variable is defined as int counter0; it will take up exactly the amount of space the compiler for that processor uses. Unlike Java, an int in C/C++ can vary in size on different processors.
It is 16bits (2 bytes) on ATmega (Arduino) and 32bits (4 bytes) on STM32F (Maple).

C/C++ will always allocate the same amount of space for a data type on the same processor (its compiler allocated location address may 'wiggle about' in memory if you ask the compiler to put a variable on 4byte boundaries, but the space used for the variable won't change).

Type promotion is sometimes used to describe how arithmetic expressions are evaluated, not how values are stored.
For example, when C/C++ does arithmetic, on an int and a long, if the int in smaller, C/C++ will compile in machine instructions to convert the int to a long, and then do the arithmetic on two longs. Comparing two numbers is treated as arithmetic.

Hence the reason the for statement never exited was because the int counter couldn't store a value bigger than an int can hold, and on an ATmega (Arduino) it's only -32769 to +32767.

So the int is promoted to a long for the comparison, but it will only ever be a value in the range that an int can hold, which on an ATmega is always less than 100000.

I feel CarlO's explanation for not optimising an empty loop which uses float variables is plausible; the compiler can't calculate at compile time how may times the loop will execute, because float arithmetic is imprecise and subject to small errors, so it can't deduce the final values of the counter variables, so it can't remove the code.

If you are concerned about not having an empty float-controlled for loop removed, try fiddling with the optimisation flags. There are a bunch of them, I usually use optimise for space (as small code fits in cache better, so ends up being quick), but there are a lot to choose from with the GCC compiler suite, one may be more aggresive, and take the code out.

HTH

PS, Leaflabs: What optimisation flags does the Maple IDE hand to the compiler?

Posted 5 years ago #
mbolivar
LeafLabs

(Hello to everybody on the forums from a new member of the LeafLabs team!)

PS, Leaflabs: What optimisation flags does the Maple IDE hand to the compiler?

Currently, we compile with the following optimization flags: -Os -march=armv7-m -ffunction-sections -fdata-sections

We also use these flags for C++: -fno-rtti -fno-exceptions

Compiler flags are not currently user-configurable from within the IDE, but if there's interest, we might fold that functionality in at some point. If you're interested in experimenting with different flags right now, you might want to jump to using our Unix toolchain:
http://leaflabs.com/docs/libmaple/unix-toolchain/

Note that direct use of the Unix toolchain is OPTIONAL, and requires that you know your way around a Unix shell / how to use make / how to program in C and C++ / etc. If you're uncomfortable with any of these, we recommend you stick with the Maple IDE.

Specifically, after you've made a fresh project (see:
http://leaflabs.com/docs/libmaple/unix-toolchain/#startingyourown)
you can check out the Makefile variables GLOBAL_CFLAGS, GLOBAL_CXXFLAGS, and LDFLAGS.

Happy hacking!

Posted 5 years ago #
leaflabsandy
Member

Quote: "(Hello to everybody on the forums from a new member of the LeafLabs team!)"

Reply: Change your "member" name to Key Master so other users can indentify you as
a leafblower.

Is your background in hardware or software or both?

BTW ... Welcome.

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.