@ Simon from Vilnius - Simon will agree with you, when the STM32F429 is offered in smaller package options (like LQFP64 and a small BGA) and the price is almost the same as STM32F405.
The additional 64 KB RAM of the STM32F429 (256 KB in total) should notably reduce the memory pressure in cases like those that Simon described in his last post.
However, these additional 64 KB would be marginally useful for a JIT compiler. So I think Simon is talking about the additional 8 MB of [em]external[/em] RAM of the new Discovery boardsā¦ Different ball game. And subsidized boards, of course.
I love this conversation as it reminds me of a time when I had way more hair and compilers were the in thing and the discussion raged on about 1 and 2 pass compilers. The more things change the more they stay the same.
1 Like
Wow, the STM32F429I-DISCO is really very low cost for what you get. Looking forward to receiving mine that I just ordered for myself. I will be using .NETMF on it. Curious to know if anyone else here already have one and how well it works. Are you using it with .NETMF or just pure C?
@ Duke Nukem - look at all the fun weāre missing: compilers were coded in assembly, internally managed overlays (self-controlled/hand-rolled virtual memory), buggy chips, minimized screen I/O because it ate too many CPU cyclesā¦that was productivity! Really cool programming languages (I wrote a linker in FORTRAN :dance: )
Ah, youāve convinced me. JIT is really the way to go on a small device, you get all the fun back 
How about a coprocessor with own RAM for JIT :whistle:
Hmm, I must be missing something. Or is deploying processor-independent code truly so important for embedded applications that one would pay for extra hardware, just to get a mediocre speedup in return?
Was meant ironically, Iād prefer AOT anyway, by this my PC would be the coprocessor.
1 Like
Got it 
Hi everybody,
FYI: Microsoft open sources more of its .Net technologies
Iām not sure if the above affects us in any way. Just wanted to share.
@ Sambo - Since the Micro Framework is one of MSās contributions to the foundation that is being created, it is good news. I hopeā¦
@ Jeff Fortran IV was my first love, after an all night coding session, there is nothing like the smell of punch cards in the morning, smells like victoryā¦
Really an AOT is what is needed and really its just a return to Fortran, write once run anywhere there is a Fortran compiler which was everywhere (remember COBOL kids). The more thing change the more they repeat themselves.
1 Like
FORTRAN isnāt any more write-once-run-anywhere than any other compiled language, such as C. Only when you use platform-specific constructs does any compiled language become non-portable.
AOT is nothing more and nothing less than a native compiler. Presumably, the C# compiler would compile the C# into IL, and then the AOT compiler would cross-compile the IL into machine code for whatever the target platform is. One could also (especially now that the C# compiler is open source) create a compiler that compiled the C# directly into native code. Just like FORTRAN does/did. Just like C does. THAT would be a MIGHTY interesting project. Marry a new ARM backend to the Roslyn C# frontend.
1 Like
Exactly. Itās just a way to make clear that one is talking about a (cross-)compiler rather than a JIT compiler.
As a historical note, and to make confusion perfect, there are also intermediate steps between JIT and AOT. A JIT compiler compiles when it first executes a piece of code (or even does interpretation for the first time and only compiles later, so that initialization code that only runs once anyway is not jitted).
When we developed a bootable hard real-time Java VM more than fifteen years ago (yes, grey hairs here, too) we couldnāt use a JIT: after all, itās kind of bad that when an interrupt handler is called for the first time, the Jitter starts to labourā¦ So we compiled upon class loading, which is tricky in order to get initialization semantics correctly. The most tricky part though was to make sure the parallel garbage collector never blocks real-time code for any length of time.
For a C# AOT compiler, the interesting thing is what it assumes about, and prescribes for, the environment it runs in. For example, it may assume that the generated native code has a way to call a system function to allocate heap memory, and it prescribes how the memory layout looks like - so that you can write a garbage collector for this environment.
Writing a compiler (to machine code) for an interpreted high level language like C# is no walk-in-the-park. For instance look at the argument mapping that goes on between C# and RPL; or, try to figure out how to implement reflectionā¦ I could go on.
I hear different complaints here: some want speed, some want compaction, some want better real-time behavior. Writing a compiler to target those different wishes is a design issue that must be dealt with up-front; otherwise, there are conflicts in code generation and optimization strategies.
I question the whole speed thing: the cure for speed should start with good profiling and call-tree analysis, then examine the algorithms for improvement. If that doesnāt work, then one small piece of RPL may be all that it takes. Depending on what youāre doing chip peripheral I/O bottlenecks may make the whole [em]go fast work[/em] a waste of time.
JIT is a shot in the dark, without run time profiling the native code may very rarely get called, the storage for the native code and the thunks to and from that code eat up memory. So unless you have lots of RAM so you can store lots of code, it just isnāt worth it (back to RPL).
For the broad class of peripherals supported, tuning for real-time is an equally large challenge, many of the peripherals (modules) are inherently asynchronous to begin with. How can you be real-time when a peripheral can interrupt the processor as demanded by itās function? Real-time is only Real where the hardware design is tightly controlled and well defined. (Iām [em]out on a limb[/em] hereā¦ havenāt done much real-time programming) Lets not forget re-writing garbage collection to be predictable.
Compaction (smaller footprint) can be performed lots of ways; just leaving pieces of the firmware out that you donāt need can buy space. Learning to write code that doesnāt lead to bloat under-the-hood is useful (some high-level constructs that make coding easy and fast are big and expensive in the IL). Eliminating redundant code through common methods is a useful tactic for size.
Bottom line: for any resource constrained device, with conflicting end-user needs, it is going to take human analysis (smart) to get it right. A generalized toolset is not going to solve the problem. For hardware with lots of resources itās a different story.
2 Likes
@ Jeff - Your comment about reflection raises an interesting point. Does a small embedded device really need reflection? Perhaps MF needs to have its functionality further trimmed to make it easier to develop a compiler. MF is for the smallest devices.There are bigger embedded .NET devices when have all the bells and whistlesā¦
1 Like
I have a whole list of things Iād give up in a heartbeat in exchange for native compilation, and reflection is right at the top of that listā¦
NETMF without reflection is not NET platform anymore for me. I would definitely not give up this for anything.
It seems that most of you complain about the speed. But if speed is the biggest issue, you should go with low level programming.
@ iamin - What reflection features do you use with embedded systems?
1 Like