8-bit MicrocontrollersのトピックRe: difference btwn the CPU clk and BUS clk

difference btwn the CPU clk and BUS clk - HCS908AW32

Denn — Mon, 03 Mar 2008 13:28:29 GMT

Hello All.

I want to know the difference btwn the CPU clk and BUS clk. HCS908AW32 has max of 20mhz bus and cpu clk of 40 mhz. Does that mean that code will run at 40 mhz??or at bus clk of 20 mhz?? Can you give me any timing diagram links?? Ultimately which has the upper hand ? Bus or CPU clk ??

Denn

Added p/n to subject.

Message Edited by NLFSJ on 2008-03-03 08:47 AM

Re: difference btwn the CPU clk and BUS clk

bigmac — Mon, 03 Mar 2008 19:43:30 GMT

Hello Denn,

The use of the term "CPU clock" within the data sheet is a little confusing, although it is stated that the bus clock frequency is one-half the CPU clock frequency. The latter is used to generate timing within the core, but the bus clock is used for access to peripherals. The timing for all instructions is based on tne number of bus cycles requred.

Regards,

Mac

Re: difference btwn the CPU clk and BUS clk

Denn — Mon, 03 Mar 2008 21:48:39 GMT

Hello Mac,

I completely agree with the fact that CPU clock is used to do operations within the core and Bus clock for operations on pheripherals.

Every instructions getting executed has four stages

1)Instruction fetch from program memory(here flash) to instruction register

2)Decoding of the instruction Opcode ( Instruction decoding)

3)Executing phase:where the Arithmatic and Logic unit of CPU is used and finally

4)Write :Here you write the results of the executing block(ALU) into memory or on the pheripheral (like I/0)

As far I understand, CPU clock is used for "Decoding" and "Execute" phase, while Bus clock for "Fetch " and "Write" phases.

Now if the CPU clock is running faster(Here twice) than Bus clock, won't it create an bottle neck situation while writing back?? To avoid this either the CPU has to wait idly doing nothing until write HW logic is free again or somesort of pipeling is required.

But I couldnot see any sort of pipeling info in the AW32 data sheet.

And again the instuctions coming from program memory to the Instr Reg is dependent on Bus clk and hence the instruction flow is dependent on BUS CLOCK.

Since both incoming as well as outgoing databus info from/out of CPU core is dependent on BUS clk, ultimately the bus clock has control on the program execution rather than whatever the CPU speed( more than 1.00) has to offer.

This is my understanding of the system.Please feel to correct me if I'm wrong.

Is there any links that you suggest me to have a look into?

Thanks in advance.

Best regards,

Denn

Re: difference btwn the CPU clk and BUS clk

allawtterb — Tue, 04 Mar 2008 00:06:13 GMT

For a more detailed explanation of commands the best place to usually look is the reference manual for the core, here is the reference manual for the HCS08:

http://www.freescale.com/files/microcontrollers/doc/ref_manual/HCS08RMV1.pdf?fsrch=1

Some places to note are:

1) Page 79 - Describes the CPU and points out the use of an instruction queue

2) Page 97 - View of what happens during a bus cycle

3) Page 199 - Provides information on the cycle-by-cycle (bus cycle) codes for each instruction.

There are many references to "CPU cycles" when they actually mean bus cycles. Take for example the NOP instruction on page 263. The operation notes that it takes one bus cycle, but in the description it says "...does nothing except to consume one CPU clock cycle...". I don't know if anyone else here has more information on the execution of commands and what takes place in relation to CPU clock cycles but I doubt it. The most information you could hope to glean is what happens from one bus cycle to the next.

Another reference is a document for the HC08, I don't know how much of this pertains to the HCS08, but I am sure a fair amount of it still holds true. It gives a better explanation of the cycle-by-cyle codes for insturctions:

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2627.pdf?fsrch=1

Hope this helps.

edit: some horrible grammer

Message Edited by allawtterb on 2008-03-03 04:12 PM

Re: difference btwn the CPU clk and BUS clk

fabio — Tue, 04 Mar 2008 00:10:28 GMT

Hi Denn,

I agree with you: the way Freescale specify its instruction timming is weird. I already asked them about such questions when I was researching for my HCS08 Unleashed book.

As far as I know, all references for instruction timming MUST be based on the BUSCLK signal, which is one-half of the CPUCLK.

I don't believe that each clock domain is used for certain phases of the instruction execution. Considering the evolution path from the HC05 to the HC08 and then to the HCS08 we can see that:

1- In the HC08, the BUSCLK signal is one fourth of the CPUCLK. This means that the instruction-rate is one-half of the HCS08.

2- The HCS08 do not implement a pipeline, instead, they use an three-byte instruction queue (which is just a prefetch buffer, simpler than a pipeline). This instruction queue allowed the designers to reduce the CPI (clock per instruction) for many HC05 instructions.

3- The increased speed of the HCS08 caused some timming problems that were addressed by changing access cycles within the instruction or by increasing the CPI of some specific instructions. While this CPI increasing caused some instructions to be 1 BUSCLK longer, this allowed them to run at double the BUSCLK rate (when compared to the HC08 CPU).

I suggest you to read AN2627, which describes the HC08 instructions using a cycle-by-cycle notation. For timming diagrams, I suggest reading section 2.4.2 of the CPU08 reference manual. Unfortunatelly, I don't know any timming chart for the HCS08 CPU.

The HCS08 family reference manual (Rev.2) also sheds some light on HCS08's instruction timming (section 6.4.6). The instruction diagrams also include cycly-by-cycle details regarding what the machine is doing in each BUSCLK cycle of an instruction.

There is more information, but I think that FS could explain them much better than I.

I hope it helps,

Re: difference btwn the CPU clk and BUS clk

Denn — Tue, 04 Mar 2008 18:57:33 GMT

Hello Fabio,

I agree with you when you say "all references for instruction timming MUST be based on the BUSCLK signal".Same info is mentioned in HCS08RMv1/D Rev. 2 05 Page

/ "In modern microcontrollers, operations are pipelined such that different parts of the circuit can be working on different information at any particular instant in time. To avoid confusion, it is important to have a single consistent point of reference so other system timing can be related to this common reference. This common reference point for the HCS08 is a bus cycle. "

Again no much info abt pipeline .!!!

To avoid confusion...A single consistent point of reference...--> Bus Clock..That doesnot mean that CPU clock is not used anywhere during instruction execution. As Mac has pointed out it is used for timing inside the CPU core.

If I read again "a single consistent point of reference so other system timing can be related to this common reference" so other system timing =??? Is this not CPU clock ??

If one sees in the instruction execution in terms of bus clock , alphabets like p,r,s,u,v,w and finally f is used.

f — Free cycle. This indicates a cycle where the CPU does not require use of the system buses. An f cycle is always one cycle of the system bus clock.

System buses are not used during f !!!! Couldn't this be the time utilised for decoding in Instruction Register and executing operations in ALU ???

How can you equate bus clock for core operations?? I don't see any logic behind this.

fabio wrote:

1- In the HC08, the BUSCLK signal is one fourth of the CPUCLK. This means that the instruction-rate is one-half of the HCS08.

I cross checked in AN2717, "M68HC08 to HCS08 Transition " it is said (page-6 .section 4.1) "CPU vs. Bus Clock
The M68HC08 CPU clock is equal to the bus clock. The HCS08 CPU clock is twice the speed of the bus"

Then how can the instruction rate of HC908 MCUs be one half of HCS series MCUs.???

Even if it was so , I don't know how you could relate CPU clock with Bus Clock in a linear way.Both are involved in different places one on bus activity and other on core activity.

fabio wrote:
2- The HCS08 do not implement a pipeline, instead, they use an three-byte instruction queue (which is just a prefetch buffer, simpler than a pipeline). This instruction queue allowed the designers to reduce the CPI (clock per instruction) for many HC05 instructions.

I agree on this ..But in HCS08 Family Reference Manual HCS08RMv1/D Rev. 2 05/2007 chapter 6 page 79

"The instruction queue improves instruction throughput because it makes the opcode and one byte of
operand information available to the CPU immediately at the start of an instruction. Without the queue,
the CPU would have to spend the first few cycles of an instruction waiting for the program information to
be fetched into the CPU. "

My doubt still remains unanswered. What about bottleneck!!!! between the execution phase (CPU clk) and write phase( Bus clock)...

N.B: This was not a problem in HC08 micros because bus= cpu clk , but in HCS08 bus clk=1/2( cpu clk)

There surely will be bottleneck condition....ultimately bus clk dictates the entire speed of the MCU!!!

And hence AN2627 will not shed info of much use on HCS08 for the above said reason.

I contacted Freescale Support.This was their reply

In reply to your Service Request SR 1-425437386:
CPU vs. BUS clocks:
******************
Well, you can forget CPU frequency. It is only marketing. It is useless for comparing HC08 and S08.
The S08 family use the same instructions as the HC08. (Four instructions have been added in S08 CPU) All instructions execution times are specified in Bus cycles on either S08 and HC08.
Many instructions have slightly different cycle counts on S08 compared to the M68HC08 Family.
But the main difference between the two families is that S08 maximum bus speed is 20 MHz and HC08 was 8 MHz.
Furthermore , the three of the four new S08 instructions improve C code compiler efficiency. The efficiency is improved in both code size and cycle counts.

I am really CONFUSED !!!!!

Re: difference btwn the CPU clk and BUS clk

peg — Tue, 04 Mar 2008 19:28:00 GMT

fabio wrote:
Hi Denn,

1- In the HC08, the BUSCLK signal is one fourth of the CPUCLK. This means that the instruction-rate is one-half of the HCS08.

This is WRONG!
HC08 the CPU and BUS clocks are the same. The CPU/BUS clock is one fourth of the source clock.
S08 the BUSCLK is half of the CPUCLK. CPUCLK = source clock.

Anything much deeper than this is pretty much black boxed for us poor users.
The main thing of note is that the CPU clock is pretty much irrelevant as anything we can touch/see is based on BUSCLK timing, this is why I believe they stuck to BUS cycles for the instruction times.

Message Edited by peg on 2008-03-04 10:31 PM

Message Edited by peg on 2008-03-04 10:37 PM

Re: difference btwn the CPU clk and BUS clk

bigmac — Tue, 04 Mar 2008 20:53:34 GMT

Hello Denn,

Denn wrote:
My doubt still remains unanswered. What about bottleneck!!!! between the execution phase (CPU clk) and write phase( Bus clock)...
N.B: This was not a problem in HC08 micros because bus= cpu clk , but in HCS08 bus clk=1/2( cpu clk)
There surely will be bottleneck condition....ultimately bus clk dictates the entire speed of the MCU!!!

Should "bottleneck" conditions happen to exist for the core or the bus, synchronisation is taken care of automatically, and need not concern the programmer. Each instruction will always take a specific number of bus cycles to execute, and is not affected by preceeding instructions. The execution cycles required for a block of assembly code is totally deterministic.

Obviously, the HCS08 will have different "bottlenecks" than the HC908, as evidenced by slightly differing number of bus cycles required to execute the same instruction.

Yes, the bus clock frequency does have a major influence on the speed of execution of a program. However, the experienced assembly programmer does have some secondary control with programming technique used, choice of addressing modes, etc.

Regards,

Mac

Message Edited by bigmac on 2008-03-05 12:01 AM

Re: difference btwn the CPU clk and BUS clk

fabio — Tue, 04 Mar 2008 21:02:45 GMT

You are right Peg,

What I meant is that the BUSCLK is actually one fourth of the oscillator clock (as you correctly pointed out).

Anyway, much of the information I wrote, I got from Jim Sibigtroth, one of the men behind the HC05, HC08 and HCS08 design.

I agree with you that, for us, the poor users, most of the CPU and the reasons for one or another feature are all inside a black box.

Again, regarding the CPUCLK of the HCS08 and the different domains of BUSCLK and CPUCLK pointed by Denn, I believe that the higher-rate CPUCLK is used to allow faster internal operations within the CPU. Here is a small paragraph I received from FS tech team:

"The much faster HCS08 bus made it impractical to keep pretending that reads and writes take the same amount of time and it also made the designers pay closer attention to the critical speed paths through the CPU. In some cases this meant using two bus cycles to do some CPU operations instead of one, but at the same time they were able to increase bus speed by significantly more than 2x without increasing the logic speed and power consumption as much as you would expect. In HCS08 the CPU can issue a new read on every bus cycle, but it cannot use the returned data in the next bus cycle like the HC08 could. At the start of a new instruction, there are two bytes of object code ready and waiting in the 2-stage instruction queue and a third byte on its way (the third read was already issued, but the data hasn’t been latched into the CPU yet)."

Unfortunatelly, I am not sure I am authorized to publish all the contents of the message.

Best regards,

Bigmac,

I completely agree with you. Questions related to the internal timmings whitin the HCS08 CPU and possible internal bottlenecks are invisible to the programmer. From the programmer's point of view, the basic concept is that the BUSCLK rules all timming within the CPU. That is it.

An LDA #5 instruction, for example, takes 2 BUSCLK cycles to complete. Change the addressing mode and the number of clock cycles will increase accordingly.

The cycle-by-cycle detais presented in the CPU section of the HCS08 device datasheets can help understanding why some modes need more cycles than others.

The cycles for LDA #5 are pp (two program fetches). The first fetch reads the opcode from the memory, the next fecth reads the operand and load it into the accumulator. It is important to note that these two bytes belong to next instruction (following the LDA instruction), because the two bytes for the LDA instruction were already loaded into the instruction queue.

The LDA opr8a, for example, takes 3 BUSCLK cycles (one more than using the immediate addressing mode) and the cycles are rpp. Considering that the instruction opcode and the operand is already loaded into the instruction queue. The first execution cycle of the instruction reads the memory address pointed by the operand and stores it into the accumulator. The two next program fetches (pp) fill the instruction queue.

Looking the same instruction (LDA opr8a) on the HC08 CPU (using the AN2627) it is easy to notice that the cycles are different: prp. This happens because the HC08 has only a one-byte prefetch buffer. The first byte of the instruction (the opcode) is already loaded into the prefetch buffer when the instruction starts, the operand is then fetched (the first p cycle), then the memory is read and the value is stored into A (the r cycle) and then the prefetch buffer is filled with the opcode of the next instruction (the second p cycle).

I think that is the way it goes (maybe I am wrong).

Best regards,

Message Edited by fabio on 2008-03-04 01:31 PM

Re: difference btwn the CPU clk and BUS clk

JimDon — Tue, 04 Mar 2008 22:31:35 GMT

There are different way to look at this.

To execute a one cycle instruction, you need a Fetch cycle to get the instruction into the instruction register. However logic needs time to propagate, as the instruction must be decoded, so you need another cycle to execute the instruction, usually called the Execute cycle.. So the cpu clock IS used, but each unit of work takes two cpu clocks to complete, and the minimum unit is one cycle.

If you have a 20Mhz "master clock", it takes 20Mhz/2 or 100ns to execute a one cycle instruction. A 2 cycle instruction take 200ns and so on.

Really thats all there is to it. A cycle takes two cpu clocks.

Other parts of the MCU (we have really been talking about the CPU) are clocked using the bus clock. In fact, it is called the bus clock, because the I/O bus runs at this rate. The bus clock is what logic external to the cpu sees.

In pipelining (which these processors do not use) the instruction is pre-decode and possibly pre executed, meaning in some cases and instruction may take 0ns to execute. The logic for this is very complex and costly not to mention power hunger. This also given variable timing on a sequence of instructions - this can make timing issues tricky to resolve.

Re: difference btwn the CPU clk and BUS clk

Denn — Tue, 04 Mar 2008 23:02:55 GMT

Hello Mac,Fabio,

bigmac wrote:

I agree on Mac,when he says as an programmer, one need not really worry about the instruction execution details in deep like timing of each micro execution details. All he needs to know( mainly assembly programmers - for say better code which executes in less time) is the timing period of entire execution of each instruction.Normally time for each instructions will be in terms of micro seconds or less. Obviously there has to be some common reference unit/terminology for their measurement.Here the common reference unit is BUSCLK. When some one says one instr takes 5 BUSCLKs he says total time taken is 5 times the bus clock.But that doesn't mean that CPU clock (core activities) are not involved during this time.Surely a good part of it will be involved.

Same info is mentioned in HCS08RMv1/D Rev. 2 05 Page

I also agree that "Each instruction will always take a specific number of bus cycles to execute, and is not affected by preceeding instructions. The execution cycles required for a block of assembly code is totally deterministic. "

My concern about "bottleneck" had got nothing to do with as an programmer but as an processor architecture enthusiast !!!!

My concern about the " bottleneck" is within the execution of a SINGLE instruction and not with the series of instructions aka preceeding instructions. Bottleneck between the core (say max speed 40 MHz and hence more throughput) and the write block (max speed of 20Mhz ).You can compare this to the Bucket with a hole in the bottom side . Yes!!! Bucket is filled with water.Now with the hosepipe you are filling water a faster rate than (say twice) the speed of water trickling out from the bottom side.It works fine for some time, then water obviously will overflow.What does that mean ?? Wasn't there a bottleneck condition at the junction of incoming water and outgoing from bucket ?This is what I was trying to convince.

Fine!!! Anyway I got the answer from Fabio where he suggests that HCS core (CONTROL AND EXECUTION BLOCKS )needs to do MORE things before write block becomes ready, and hence increase in the speed of core clock..

May be, if this CPUclock was slow(than the current twice speed) and HCS core had not completed its tasks before write block was ready, obviously the write block had to wait until the EXECUTION BLOCKS gives its result to write block (Bucket empty condition).Seeing all these possibilities Freescale hardware designers might have given the CPU clock a higher speed compared to bus clock.And hence no overflow or empty condition....Everything has got to do with HW hardwired logic. SW Programmers have no control over them. All they want is the time of each instruction.Here the time is measured interms of BUSCLK!!! (reference **bleep** for measurement of instructions)

Best regards Denn

Re: difference btwn the CPU clk and BUS clk

fabio — Tue, 04 Mar 2008 23:52:35 GMT

Hi Denn,

I am a processor architecture enthusiast too! I understand your questions but you must also understand that **most** people here do not work for FS, therefore, we have no access to such details of the processor design. All we can do is speculate about the ways to do it and the reasons to do it, but everything lies in the theorical field.

I like to design CPUs using VHDL language and sometimes I would like to know why some comercial designs choose one way instead of another. But unfortunatelly, processor designing is a more complex task than just make it work correctly. There are many tradeoffs that must be cared about (cost, complexity, power consumption, etc).

From the designer's point of view, a higher clock rate means more clock edges to do useful things (like fetching, decoding, executing, etc). My first CPUs were clock-hungry devices that needed several clock pulses to perform simple tasks. As the time goes by, you start to notice that some cycles can be used to make some tasks in paralell and so on.

And talking about clocks remainds me Microchip and their "one instruction per machine cycle" hype. I remember that many people believed that a PIC could execute one instruction at each clock cycle and that isn't true because a machine cycle actually takes four clock cycles (and I believe this remains true even on the newest DsPIC devices). Again, the higher clock is internally used to feed the logic mechanisms within the CPU, but the instruction rate is measured in terms of machine cycles.

Before I go, I would like to know what are those four new HCS08 instructions mentioned by the FS tech support guy. As far as I know, regarding the HC08, only one instruction was added to the HCS08 (BGND). The better C optimization is enabled by the new addressing modes added to the existing CPHX, STHX and LDHX instructions.

Best regards,

Re: difference btwn the CPU clk and BUS clk

JimDon — Tue, 04 Mar 2008 23:54:37 GMT

After re-reading my post, I realized I used the term cycle in an ambiguous manner.
I have replaced this with term sub-cycle to indicate a cpu clock.

To execute a one cycle instruction, you need a Fetch sub-cycle (one cpu clock) to get the instruction into the instruction register. However logic needs time to propagate, as the instruction must be decoded, so you need another sub-cycle to execute the instruction, usually called the Execute sub-cycle. So the cpu clock IS used, but each unit of work takes two cpu clocks to complete, and the minimum unit is one cycle.

If you have a 20Mhz "master clock", it takes 20Mhz/2 or 100ns to execute a one cycle instruction. A 2 cycle instruction take 200ns and so on.

Really that's all there is to it. A cycle takes two cpu clocks.

Re: difference btwn the CPU clk and BUS clk

fabio — Wed, 05 Mar 2008 00:43:42 GMT

BTW.: the HCS08 instruction queue is two bytes long and not three as I said before. Sorry for that ...

Best regards,

Re: difference btwn the CPU clk and BUS clk

peg — Wed, 05 Mar 2008 05:47:37 GMT

fabio wrote:

Before I go, I would like to know what are those four new HCS08 instructions mentioned by the FS tech support guy. As far as I know, regarding the HC08, only one instruction was added to the HCS08 (BGND). The better C optimization is enabled by the new addressing modes added to the existing CPHX, STHX and LDHX instructions.

The tech support guy probably understood this paragraph wrongly from AN2717. (As many would, it is poorly written and badly illustrated by the table.)

_________________________________
New opcodes:

The instruction to enter the new background debug mode, BGND, has been
added to the original M68HC08 opcode map. To improve C code compiler
efficiency, several addressing modes for manipulating the 16-bit H:X index
register have been added to the original three instructions. A total of 10 new
opcodes have been added to the M68HC08 opcode map, as shown in Table 1.

Table 1. New HCS08 Opcodes
Instruction Addressing Mode(s) New Opcodes
LDHX EXT,IX,IX1,IX2,SP1 $32,$9EAE,$9ECE,$9EBE,$9EFE
CPHX EXT,SP1 $3E,$9EF3
STHX EXT,SP1 $96,$9EFF
BGND INH $82
____________________________________

The table mixes up the new instruction with the new addressing modes that when used with certain instruction provide greater C compiler efficiency.
It then goes on to say that 10 new codes have been added to the opcode map.
There are 10 in the table but some of them are not new.
This lousy document (in Rev. D) fails to even address the new addressing modes and in their scant mention here implies that they only apply to these three instructions which is of course incorrect.

Why there is someone in technical support quoting flawed documentation without understanding that it is incorrect at this very basic level is another question altogether.

Message Edited by peg on 2008-03-05 08:53 AM

Re: difference btwn the CPU clk and BUS clk

JimDon — Wed, 05 Mar 2008 05:55:59 GMT

As far as the cpu is concerned, for all intents and purposes, a new addressing mode IS a new instruction.
- It has a new opcode. I would say this alone qualifies it as a new instruction.
- It provides new functionality.
- From the VHDL point of view, new micro code needs to be added to execute the instruction
- The instruction decoder logic needs to be changed to decode it.

It think it is fair to say it is a new instruction.
Maybe in your opinion this does not fit the definition of a new instruction, but I think you can see a point of view where it does. Both engineering and marketing. The CPU engineer had to to the work of adding a new instruction.

Re: difference btwn the CPU clk and BUS clk

peg — Wed, 05 Mar 2008 06:02:14 GMT

Hi Jim,

I think you have missed the point.
I am not contesting whether or not a new addressing mode for an instruction qualifies as a "new instruction".
I agree with what you have said just now.

What is a issue is the number four (4).

Re: difference btwn the CPU clk and BUS clk

JimDon — Wed, 05 Mar 2008 06:46:38 GMT

I seem to be missing a lot of points today :smileyhappy:.,

Actually I was responding to:

"As far as I know, regarding the HC08, only one instruction was added to the HCS08 (BGND). The better C optimization is enabled by the new addressing modes added to the existing CPHX, STHX and LDHX instructions."

And just explaining why and addressing mode might qualify as a new instruction.
And then it might not, depending on how marketing felt that day....
As for tech support usually their job is to quote what's there, and they may not be even given the time to question it.

I'd just be happy if the would the RM to show all the instructions.

Re: difference btwn the CPU clk and BUS clk

peg — Wed, 05 Mar 2008 07:19:48 GMT

Actually after more checking I see that the current version of AN2717 is Rev. 1
A, B, C, D, 1 ????
Perhaps it started to look embarrasing.
But still the paragraph/table persists.
As no revision history is included I do not know what was changed.
Perhaps it was just the Motorola to Freescale changes.
Whether this warrants the attribution to a new author is questionable, he obvoiusly did not read and understand it.

Re: difference btwn the CPU clk and BUS clk

bigmac — Wed, 05 Mar 2008 13:43:27 GMT

Hello Peg,

Peg wrote:
_________________________________
New opcodes:

The instruction to enter the new background debug mode, BGND, has been
added to the original M68HC08 opcode map. To improve C code compiler
efficiency, several addressing modes for manipulating the 16-bit H:X index
register have been added to the original three instructions. A total of 10 new
opcodes have been added to the M68HC08 opcode map, as shown in Table 1.

Table 1. New HCS08 Opcodes
Instruction Addressing Mode(s) New Opcodes
LDHX EXT,IX,IX1,IX2,SP1 $32,$9EAE,$9ECE,$9EBE,$9EFE
CPHX EXT,SP1 $3E,$9EF3
STHX EXT,SP1 $96,$9EFF
BGND INH $82
____________________________________

The table mixes up the new instruction with the new addressing modes that when used with certain instruction provide greater C compiler efficiency.
It then goes on to say that 10 new codes have been added to the opcode map.
There are 10 in the table but some of them are not new.
This lousy document (in Rev. D) fails to even address the new addressing modes and in their scant mention here implies that they only apply to these three instructions which is of course incorrect.

I don't have too much issue with the quoted paragraph from the application note. It explicitly states that they are new opcodes. For the opcodes listed in Table 1, I believe they are all new to HCS09 - I could not find them in the instruction summary for the HC908.

A possible ambiguity might be the use of the phrase "the original three instructions". Here it becomes slightly clearer if the word mnemonic is substituted for instruction. And we possibly avoid the "splitting of hairs".

Regards,

Mac