Author Topic: No more code-size-limited version of IAR embedded workbench for ARM?  (Read 12852 times)

0 Members and 2 Guests are viewing this topic.

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3301
  • Country: ca
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #100 on: November 30, 2024, 08:46:25 pm »
I remember this asm volatile from 1990's.

Back then the compilers simply printed the asm text to the output without trying to parse or interpret it. They wouldn't know what to do with volatile.

The optimization obsession hasn't started until much later - ca 2005 - 2010.
 
The following users thanked this post: 5U4GB

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 4411
  • Country: gb
  • Doing electronics since the 1960s...
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #101 on: November 30, 2024, 10:50:43 pm »
There are much bigger experts than me here but my impression is that the compiler business ran out of stuff to do and started going sideways. What clever gimmicks can we do?

Same as the MbedTLS development for example. So many changes, to upgrade to the latest whizz bang version, which does hardly anything useful and nothing useful that needed such changes.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: 5U4GB

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #102 on: November 30, 2024, 10:53:31 pm »
There are much bigger experts than me here but my impression is that the compiler business ran out of stuff to do and started going sideways. What clever gimmicks can we do?
Unless a compiler can consistently match what an assembly language programmer can achieve, especially for parallel code, I think compiler designers still have plenty to do.
 
The following users thanked this post: neil555

Offline cfbsoftware

  • Regular Contributor
  • *
  • Posts: 137
  • Country: au
    • Astrobe: Oberon IDE for Cortex-M and FPGA Development
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #103 on: November 30, 2024, 11:46:11 pm »
The stupidest thing here is that 99% of the time complaints about "C"'s "quirks" apply to every imaginable alternative and replacement as well.
Somewhat of an exaggeration I believe. A more accurate observation might be:
Quote
It should be noted that complaints about C's quirks often apply to other popular alternatives and replacements as well.
Chris Burrows
CFB Software
https://www.astrobe.com
 

Offline rfindley

  • Contributor
  • Posts: 20
  • Country: us
  • Embedded Systems Contractor
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #104 on: December 01, 2024, 03:00:01 am »
Getting back to the OP's question...
Do a google search for "IAR Kickstart" plus whichever processor family you want to use.  IAR doesn't talk about the Kickstart versions on their website, at least not that I've seen, so it's understandable to wonder whether it's still available.

On another note, if you're a Visual Studio user and you've never seen VisualGDB (a companion for Visual Studio), it's worth checking out. They have a lot of pre-built gcc toolchains, and it takes a lot of the pain out of setting up a gcc workflow.  I used it on a project a few years ago to write my code on Windows/Visual Studio, cross-compile on a Linux build server, deploy to target hardware, and remote-debug, all from inside Visual Studio + VisualGDB.

Honestly, though, I rarely use VisualGDB (or Visual Studio, for that matter).  For debugging, I mostly use a printf-style 'dlog' library that I've built over the years.  It lets me dynamically change what I log by topic and log-level, using whatever log destination I have available on a given target board (memory, serial port, file, log server, etc), and you can use it on almost any processor.  Once you get used to troubleshooting that way, an actual debugger starts to feel cumbersome.
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 634
  • Country: au
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #105 on: December 01, 2024, 04:47:04 am »
Abusing a language keyword to fix a problem they created themselves isn't the triumphal feat of software engineering that you (and the GCC authors) seem to think it is.

Another example of this is gcc's -fno-delete-null-pointer-checks.  It'd be like having a car where, each time to start it, you have to remember to specify -fno-ignore-brake-pedal.  It could be straight out of an episode of Wellington Paranormal:

"Once again we've come up with a perfect solution to the problem".
"That we caused".
"Job well done".
"Good result".
 
The following users thanked this post: KE5FX

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 4411
  • Country: gb
  • Doing electronics since the 1960s...
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #106 on: December 01, 2024, 08:28:40 am »
Quote
Unless a compiler can consistently match what an assembly language programmer can achieve, especially for parallel code, I think compiler designers still have plenty to do.

Sure, but trying to catch weird stuff like variables which the coder explicitly declared but which have no effect (resulting in the whole "volatile" business) is a waste of resources which in most/all cases will have a negligible impact on speed or code size.

I've been coding asm since 1975 or so and anybody who has done a lot of asm will know where the tricks are. It is stuff like analysing the whole bit of code and stuffing the values into registers. And using various tricks. But in the end it makes little difference since "tricks" can also be coded in C, and in most projects the CPU spends most of its time running a very small part of the code.
« Last Edit: December 01, 2024, 08:51:29 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3577
  • Country: it
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #107 on: December 01, 2024, 10:16:46 am »
I wonder if i would quote myself from earlier in this thread: who knows how many of these discussions we would not have if the world stopped using GCC altogether and moved to CLANG
one that peter, and many others, probably don't know, in their never ending quest of beating the compiler with tricks and asm level optimization: GCC can't possibly know which non-static functions are never called (though clang can), go enable --gc-sections and see what remains when you start using function pointers

Incredibly fun if you need to detect and remove dead code, makes a case for very expensive libraries for run time profiling, with all their side effects
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 634
  • Country: au
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #108 on: December 01, 2024, 10:19:19 am »
Same as the MbedTLS development for example. So many changes, to upgrade to the latest whizz bang version, which does hardly anything useful and nothing useful that needed such changes.

What were/are the issues with MbedTLS?  It's always useful to get experience-based details on pain points.
« Last Edit: December 01, 2024, 10:22:38 am by 5U4GB »
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 4411
  • Country: gb
  • Doing electronics since the 1960s...
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #109 on: December 01, 2024, 01:27:02 pm »
Quote
one that peter, and many others, probably don't know, in their never ending quest of beating the compiler with tricks and asm level optimization: GCC can't possibly know which non-static functions are never called (though clang can), go enable --gc-sections and see what remains when you start using function pointers

I use almost no asm with arm32 - no need for it, given 7ns cycle time :) I've used it only for "min time delay" timing loops, especially for microsecond-level waits.

Unused functions are basically irrelevant when you have 1MB FLASH and even after years you have filled only half of it.

And, to make you laugh, I never use function pointers in C :) In asm, yes, they are commonly used. They are used in ST's ETH and USB code to invoke different bits of code but they are really pointless (when selecting one of about 4 options) and just make the code more opaque, especially given their taste for typedefs of typedefs of typedefs ;)

Quote
Incredibly fun if you need to detect and remove dead code, makes a case for very expensive libraries for run time profiling, with all their side effects
One can do profiling for nothing if there is a "tick" or an RTOS
https://www.eevblog.com/forum/microcontrollers/freertos-where-should-the-cpu-be-spending-most-of-its-time/msg4965922/#msg4965922

Quote
What were/are the issues with MbedTLS?  It's always useful to get experience-based details on pain points.

The MbedTLS integration in my project was done by someone else (at version 2.16.2) but I am on their mailing list. If you want TLS 1.3 then you have to use MbedTLS v3+ but AFAICT nobody currently uses TLS 1.3 in the industrial control sphere. They added stuff like zeroing malloc'ed buffers before freeing them, which is "good practice" but only if somebody is already poking about inside your product...  Then they stripped out "deprecated" (always a good word to impress internet security experts) crypto suites like DES/3DES (which AFAICT nobody at all uses anywhere) only for you to have to add some back in because some of the certificates in cacert.pem have signatures done with old hashes :) They have added ChaChaPoly, which is ok but AFAICT nobody insists on that if you present AES256. So, some handy bit perhaps and OK if you are implementing it now, but basically years of going sideways, IMHO, especially given that IMHO an IOT box should be a client and not on an open port. They have not done really handy stuff like processing the certificates file one cert at a time so it needs ~300k of spare RAM (there is a 3rd party mod for this which my box has).
« Last Edit: December 01, 2024, 01:45:29 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #110 on: December 01, 2024, 05:41:35 pm »
I wonder if i would quote myself from earlier in this thread: who knows how many of these discussions we would not have if the world stopped using GCC altogether and moved to CLANG
Why would CLANG, or any other compiler, affect the discussion much. All modern compilers have reached the stage where they optimise well enough for all sorts of things to show up, which rarely used to.
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #111 on: December 01, 2024, 05:47:11 pm »
Quote
Unless a compiler can consistently match what an assembly language programmer can achieve, especially for parallel code, I think compiler designers still have plenty to do.

Sure, but trying to catch weird stuff like variables which the coder explicitly declared but which have no effect (resulting in the whole "volatile" business) is a waste of resources which in most/all cases will have a negligible impact on speed or code size.
Are you saying you think volatile is globally an annoyance, or just in the cases where it directly annoys you? Thinking that code should always go back to the memory location would be a interesting performance hole for a wide range of code. Much of what happens when you turn on optimisation is using registers to avoid going back to memory too often.
 

Offline mark03Topic starter

  • Frequent Contributor
  • **
  • Posts: 750
  • Country: us
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #112 on: December 01, 2024, 05:53:48 pm »
Getting back to the OP's question...
Do a google search for "IAR Kickstart" plus whichever processor family you want to use.  IAR doesn't talk about the Kickstart versions on their website, at least not that I've seen, so it's understandable to wonder whether it's still available.
That search doesn't return anything useful when I do it.  Some vendor-specific pages and the occasional IAR press release, all of them old.  Are you seeing anything different?
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #113 on: December 01, 2024, 05:57:13 pm »
Getting back to the OP's question...
Do a google search for "IAR Kickstart" plus whichever processor family you want to use.  IAR doesn't talk about the Kickstart versions on their website, at least not that I've seen, so it's understandable to wonder whether it's still available.
I thought IAR Kickstart was a specific deal IAR has with TI for a limited version of IAR for the MSP430.
 

Offline KE5FX

  • Super Contributor
  • ***
  • Posts: 2111
  • Country: us
    • KE5FX.COM
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #114 on: December 01, 2024, 06:59:37 pm »
It lets me dynamically change what I log by topic

Hmm.  I like this idea.  Seems obvious enough but I've never seen it done. 

A scalar 'message threshold' is never really granular enough in a non-trivial application, but tagging debug messages with arbitrary keywords could change that.
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #115 on: December 01, 2024, 07:10:38 pm »
Honestly, though, I rarely use VisualGDB (or Visual Studio, for that matter).  For debugging, I mostly use a printf-style 'dlog' library that I've built over the years.  It lets me dynamically change what I log by topic and log-level, using whatever log destination I have available on a given target board (memory, serial port, file, log server, etc), and you can use it on almost any processor.  Once you get used to troubleshooting that way, an actual debugger starts to feel cumbersome.
For desktop or server debugging I agree with you. Debuggers have their place when things get really weird, but they are a last resort rather than a first.... although they will often bring their own quirks, making you regret resorting to them. Embedded is a bit different, though. Your limited ability to interact with an embedded target often makes a debugger more valuable. You'll probably need one just to get code into the target, anyway.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3577
  • Country: it
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #116 on: December 01, 2024, 10:54:16 pm »
I wonder if i would quote myself from earlier in this thread: who knows how many of these discussions we would not have if the world stopped using GCC altogether and moved to CLANG
Why would CLANG, or any other compiler, affect the discussion much. All modern compilers have reached the stage where they optimise well enough for all sorts of things to show up, which rarely used to.

though GCC by the way the way it's written can't find unused functions reliably, can't, or won't, warn about obvious bugs a la "sizeof(x - 2)" when the programmer obviously meant "sizeof(x) - 2", signal that statements are always true/false, hence will be optimized away, and such other things. I say Clang, but i wouldn't be surprised that any other compiler frontend is more effective than GCC in finding bugs and static analysis

@peter, well function pointers is something i rarely use as well, only when i really want them. i.e.: i have like a dozen different sets of functions with the same interface, think of it as device drivers, i didn't want to pollute the code with a set of ever growing switch statements, function pointers were a much more elegant solution IMHO. But function pointers + -gc-sections is guaranteed to break your day. Also, profiling is one thing, and very important, but the compiler should be able to determine dead code from just compiling (after all, it does know all the call trees, all the function entries, and even if functions that are called indirectly are actually set to be called. GCC won't and the garbage collector results in a mess deleting parts of used code. Profiling comes afterwards, functions and statements that *should* execute, but are never due to conditions that never present themselves.
Another problem is when you write functions, you think they are being called and they're not. Waste a day chasing a bug only because stupid GCC won't tell that function X is unused
 

Offline mark03Topic starter

  • Frequent Contributor
  • **
  • Posts: 750
  • Country: us
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #117 on: December 01, 2024, 10:54:33 pm »
Getting back to the OP's question...
Do a google search for "IAR Kickstart" plus whichever processor family you want to use.  IAR doesn't talk about the Kickstart versions on their website, at least not that I've seen, so it's understandable to wonder whether it's still available.
I thought IAR Kickstart was a specific deal IAR has with TI for a limited version of IAR for the MSP430.
It used to be a generic thing (at least for EW-ARM), and you could select a time-limited OR code-size-limited version, your choice.  But they may have had special deals with silicon vendors as well.

Anyhow, I'm 99% sure this is no more, so the original question is answered.  You may now return to the compiler wars ;)
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 634
  • Country: au
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #118 on: December 02, 2024, 05:30:06 am »
The MbedTLS integration in my project was done by someone else (at version 2.16.2) but I am on their mailing list. If you want TLS 1.3 then you have to use MbedTLS v3+ but AFAICT nobody currently uses TLS 1.3 in the industrial control sphere. They added stuff like zeroing malloc'ed buffers before freeing them, which is "good practice" but only if somebody is already poking about inside your product...  Then they stripped out "deprecated" (always a good word to impress internet security experts) crypto suites like DES/3DES (which AFAICT nobody at all uses anywhere) only for you to have to add some back in because some of the certificates in cacert.pem have signatures done with old hashes :) They have added ChaChaPoly, which is ok but AFAICT nobody insists on that if you present AES256. So, some handy bit perhaps and OK if you are implementing it now, but basically years of going sideways, IMHO, especially given that IMHO an IOT box should be a client and not on an open port. They have not done really handy stuff like processing the certificates file one cert at a time so it needs ~300k of spare RAM (there is a 3rd party mod for this which my box has).

Thanks, good to know.  I've found the same with TLS 1.3 in embedded/SCADA, it essentially doesn't exist, at least one reason being that despite its name it's a completely new protocol that needs a second protocol stack alongside the pre-1.3 one.  Heck, there are still a lot of systems using TLS 1.0, but people are slowly battling to get their successor systems to TLS 1.2.

The reason for the ChaChaPoly nonsense is that Google insists on presenting oddball non-MTI (mandatory to implement) algorithms in its TLS 1.3 handshake so you have to go back and tell it to use MTI algorithms instead, for an extra round trip that completely defeats all the compromises they made in TLS 1.3 to try and reduce round trips.  Specifically, they use Curve25519 instead of ECDH/ECDSA for the crypto, but since Google is bigger than the Internet everyone has to change their code to copy what Google does.  So that one isn't really mbedTLS' fault, you can blame Google for that one.

More generally, the TLS folks never stop churning the specs to accommodate whatever flashy thing is coming down the road.  If you think the TLS 1.3 changeover was painful, wait until all the post-quantum crypto bollocks starts hitting.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 9430
  • Country: fi
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #119 on: December 02, 2024, 10:32:44 am »
Sure, but trying to catch weird stuff like variables which the coder explicitly declared but which have no effect (resulting in the whole "volatile" business) is a waste of resources which in most/all cases will have a negligible impact on speed or code size.

Bullshit. Try qualifying every variable in your program volatile and see what happens. I can assure you the impact on speed and code size is not "negligible". Volatile is in C from the very beginning and for a very good reason. You will fail miserably even at -O0, and even with 1990's compiler if you do not understand when to use volatile.


BTW, did you guys already find any real-world example where GCC has started stripping out asm statements so that the intended behavior broke? Or are you complaining just in case? It would seem quite odd to me that one learns to use GCC Extended Asm, learns the concepts and syntax of defining Inputs, Outputs and Clobbers, but misses the part about volatile, then writes a program using extended asm using those inputs, outputs and clobbers, the whole purpose of which is to enable optimizations, and then get surprised that GCC indeed did use inputs, outputs and clobbers to perform said optimization?
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 9430
  • Country: fi
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #120 on: December 02, 2024, 10:45:43 am »
Another example of this is gcc's -fno-delete-null-pointer-checks.  It'd be like having a car where, each time to start it, you have to remember to specify -fno-ignore-brake-pedal.

Another alarmistic exaggeration: for example, I have never used -fno-delete-null-pointer-checks, and did not even know about it before this thread. I have never seen any project use it. And I have never seen any issues caused by this feature.

Compare to your car example: I'm quite sure that if cars habitually ignored brake pedals, I would have seen it.

I would also expect to see more discussion about delete-null-pointer-checks if it was a serious problem.

As usually, correct explanation can be found in documentation:
"these assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already been dereferenced, it cannot be null. ... Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior. "

So the correct car analogy is: "brake pedal can break after the car crashes, because brakes are not normally needed anymore. If reinforced brake structure which can withstand a full crash is needed in special environments, use -fno-allow-brakes-that-cannot-withstand-crashes".

But I'm sure you are not happy with the correct analogy and prefer your own alarmistic one instad.

And, BTW, performance differences can be significant. If you try to write robust code which is aimed at the human reader, you may as well place a NULL pointer check inside a loop which is iterated millions of times. If a compiler can prove that the check has been done already and cannot fail, I'm very happy to have that optimization. It's a huge timesaver, and I don't want to go back to the 1990's where compilers needed micromanaging statements out of loops for decent performance. And really, it was just easier not to check. Now the compiler often knows if the check is needed and can remove the check if statically deemed unnecessary.
« Last Edit: December 02, 2024, 10:50:53 am by Siwastaja »
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #121 on: December 02, 2024, 03:07:21 pm »
Volatile is in C from the very beginning and for a very good reason.
No it wasn't. It was a high priority requirement, yet still didn't make it in until 2001. There were lots of fudgy approaches, like "attribute" constructs, used before volatile was settled on.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 9430
  • Country: fi
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #122 on: December 02, 2024, 03:36:45 pm »
No it wasn't. It was a high priority requirement, yet still didn't make it in until 2001

Wat? You can definitely see that it was present in C89 / ANSI C in 1990 (see e.g. https://www.yodaiken.com/wp-content/uploads/2021/05/ansi-iso-9899-1990-1.pdf )

Or do you mean compiler support for it was lacking before 2001?
 
The following users thanked this post: newbrain

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10121
  • Country: gb
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #123 on: December 02, 2024, 03:40:06 pm »
No it wasn't. It was a high priority requirement, yet still didn't make it in until 2001

Wat? You can definitely see that it was present in C89 / ANSI C in 1990 (see e.g. https://www.yodaiken.com/wp-content/uploads/2021/05/ansi-iso-9899-1990-1.pdf )

Or do you mean compiler support for it was lacking before 2001?
Interesting. It certainly wasn't in K&R, so I knew it wasn't there from the start. I just Googled when it was added, and I got 2001 as the result. Maybe that was given with the precision of an AI result. :)
 
The following users thanked this post: Siwastaja

Offline jfiresto

  • Frequent Contributor
  • **
  • Posts: 900
  • Country: de
Re: No more code-size-limited version of IAR embedded workbench for ARM?
« Reply #124 on: December 02, 2024, 04:17:24 pm »
No it wasn't. It was a high priority requirement, yet still didn't make it in until 2001

Wat? You can definitely see that it was present in C89 / ANSI C in 1990 (see e.g. https://www.yodaiken.com/wp-content/uploads/2021/05/ansi-iso-9899-1990-1.pdf )

Or do you mean compiler support for it was lacking before 2001?
Interesting. It certainly wasn't in K&R, so I knew it wasn't there from the start. I just Googled when it was added, and I got 2001 as the result. Maybe that was given with the precision of an AI result. :)

It is in the second edition of K&R, even if some may consider it a new testament heresy.
-John
 
The following users thanked this post: Siwastaja


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf