Walter Banks's blog
Byte Craft has for the last several months been developing new eTPU
support tools. The eTPU C Code Development System will continue to be
supported for use primarily in automotive engine controllers with
continuing support for eTPU2, new releases and updates.
The last few months we have be visiting customers and outlining some
directions we are adding to our support for the eTPU. Byte Craft is in
the release process of a separate eTPU based tool set that focuses on
other eTPU based applications. Essentially we have been looking at
The Freescale eTPU standard library and eTPU function sets were developed using Byte Craft tools. Copies of these tools are available as part of Byte Craft eTPU support.
Contact Byte Craft for headers for the new RS-08 part headers.
9RS08KB8.h 9RS08KB4.h 9RS08KB2.h 9RS08KB12.h 9RS08LE4.h 9RS08LA8.h
The RS-08 parts that support interrupts (9RS08KB8.h 9RS08KB4.h 9RS08KB2.h) may also be programmed as event driven processors.
Byte Craft's eTPU customers generally use several different tools in their eTPU toolchain. The eTPU has a microcoded instruction set that may display the disassembly of the eTPU's instruction in several ways. The following example came from a conversation with a customer about instruction display formats of various tools that support the eTPU.
Byte Craft chose to display the instructions in the listing file as a functional representation of the instructions. In the following example an add with one side of the alu complimented and incremented is displayed as a subtract in our listings which is both functionally correct and a more compact representation.
In the comp.arch newsgroup, we've been following a heated discussion about Parallelism. It's focused on the question of designing software to run on multiple cores, either with shared memory or message passing.
We're of the opinion that the compiler can assist the developer in this task. After all, the compiler knows what is (or could be) in memory at any one moment.
Just when you think an old misconception is dead...
The "stack/no stack" discussion has arisen again. We've heard renewed
claims that C programs require a hardware stack, and that a software
stack is unacceptably slow. Both ideas are patently false.
A support question brought up an interesting optimization topic: alternative opcodes.
We've all heard stories of using undocumented or unofficial opcodes to squeeze out a few cycles' extra performance. It's much easier, not to mention safer, to work within the published instruction set but to approach it in novel ways.
Here's an example:
C macros are very useful, but a little taxing for both compiler writers and programmers.
I just read Jack's editorial on Embedded.com on the RS08 processor. This is a fun little processor.
We did some work on the instruction set design on this processor, and wrote a C compiler for the RS08. This is a remarkable little processor that, in the end, outperformed many people's expectations (including mine).