Mouser Electronics is now a global reseller of Byte Craft Code development tools. Byte Craft welcomes Mouser as the latest reseller of Byte Craft products.

Mouser is a customer focused distributor representing more than 450 manufacturers with more than 8 million products. We are our proud of our assocation with Mouser to continue our support our our customers and their application development needs.

Mouser Electronics
(800)346-6873

Byte Craft welcomes Qast Singapore Pte Ltd providing sales services to our customers in Singapore.

SINGAPORE

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.

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.

There's only so much debugging information an LED or LCD display can report. What's worse, embedding debugging code in the executable can provoke misuse, while stripping it out can cause heisenbugs.

Your C compiler can help manage debugging information for you in a way that doesn't interfere with your product. Here's how:

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: