@firstname.lastname@example.org - 4 reasons: 1) New architecture. Does things other architecures don't, lots of new hardware logic. 2) Proprietary machine language - Any translation from a current Forth would practically be a write from scratch anyway. 3) Different operators - I'm used to C, so as much as possible I am changing standard Forth ops to their C equivalents. Might as well piss off all the Forth user groups at the same time! 4) I'm interested in HLL design generally, so starting from scratch is the best way for me to learn anyway.
@RajuK- Compring compilers is difficult. There are some benchmarks, but usually the benchmarks are so different from you own application that they are not a good predictor. Mostly you learn from experience or from other engineers... Optimizing compilers tend to be better, but they can also cost alot more...
@gamatec- Superscaler processors typically execute multiple instructions at a time. For example, they can do a logical operation, and arithmetic operation at the same time. This is possible because the have multiple execution units (multiple ALus for example).
Response to earlier question: Do you typically have a tight 'inner loop' in your algorithms that is critical for high-performance? Have done so on occassion, but typically rely on a main loop and interrupts.
Response to earlier question: Do you typically start a design with existing code in place or start from 'scratch'? Depends on the assignment. I have worked both to complete other designs, and on new designs from scratch.
@Dev.khan- These days the embedded industry is looking for embedded programmers with experience in specific algorithms (as well as a track record of successful designs). Motor control for example is a popular algorithm...
@Dev.khan- I don't have any specific recommendations for a book on CM-3. Check out the MCU site however or go over to Microcontroller Central and ask a question on the site. That might give you some ideas.
There is a feature call 'Isochonous Operation' which means clock/synchronous I/O for the PLC. The overall module loop has a very tight timing requirement. The interrupts are usually handled with assembly and many of the control processes are handled with assembly in order to meet very strict timing.
I am typically leveraging on existing code. Typically I am pulling from two or three sources merging source as well. Mixed assembly and C code, and at times I have to try and translate between assembly source based on the used MCU.
"Since its beginning in 1974 as a small group of specialists in a previously unknown discipline, ACM SIGGRAPH has evolved to become an international community of researchers, artists, developers, filmmakers, scientists, and business professionals who share an interest in computer graphics and interactive techniques.
If I can comunicate with you in private I could pass you an interensiting link about him
@Mark.Browne- Excellent point about compilers with multiple MCU targets. Some of the optimizing compilers can eliminate the more 'generic' code that gets generated but the 'simple' compilers we get for free from the MCU manufacturers may not have these features available. (You might need to pay for them).
Development Tools: Perhaps the best way to start out is to use the MCU manufacturers free tools- either an evaluation version of a 3rd party tool or the MCU manufacturers own version. That way you can try it out before purchasing something. Check out the website of the MCU manufacturer you are targeting and you will usually find the tools right away.
The streaming audio player will appear on this web page when the show starts at 2 PM Eastern time today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. If that doesn't work, the class will be archived immediately following our live taping.
Oops - I should add that stack frame addressing is not very efficient with the Z80. This speaks to the general case that complier writers are likely to use the same general methods for all the compilers they make. If one of the targets does not implement that method very well the generated code is likely to suffer.
I should add that stack frame addressing is not very efficient with the Z80. This speaks to the general case that complier writers are likely to use the same general methods for all the compilers they make. If one of the targets does not implement method that very well the generated code is likely to suffer.
@Mark.Browne- Thanx for the decription. Uniform calling conventions can add some overhead so that is a good one to look at. More modern optimizing compilers might catch some of these inefficiencies, but it is still good to keep them in mind, and to look at your generated code once in a while to see what improvements have been made. I will bring this point up in todays class. Thanx!
This was an older compiler so I am not sure if it still relevant today.
That said - There was much data movement to and from the stack to support uniform calling conventions. There was a good deal of promotion and testing to 16 bit that was not strictly needed; I suspect that modern optimizing compliers don't do this.
@Mark.Browne- Doing that type of comparison is very valuable. Did you notice any particular areas (types of functions) where your C implementation was particularly inefficient with respect to code size?
After a large project writing assembly language to interface with existing C code and replace some C code. This was due to severe space constraints; I was able to get about a 10% code shrink which allowed the needed code enhancements to fit in the ROM. As I went through each routine I could see how each C token was implemented in assembly language by the compiler. It was a most educational process. I can now see what C does and how it does it; I think of C as pretty assembly language.
@wonohkim, not true. Yes C and assembly are the popular languages for MCU because they simply are the most commonly supported, but there are several languages that support control register and memory maps.
Truchard will be presented the award at the 2014 Golden Mousetrap Awards ceremony during the co-located events Pacific Design & Manufacturing, MD&M West, WestPack, PLASTEC West, Electronics West, ATX West, and AeroCon.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.