Just had a peek at the MAXQ document you referred us to.

My favorite line in it is "Furthermore, the modular organization of the
MAXQ system and peripheral resources leads to compiler optimizations ...".

What it should say is "leads to excedrin headaches for compiler developers
everywhere...". 

One thing that compiler developers (well, me anyway) really hate is
"residual control", which is basically registers selecting other
registers.

In the MAXQ, there is the AP register, which selects which of the
accumulator you can actually do things to. So a C code generator
is either going to either just set the AP to a fixed value (and
have one destination accumulator) or else jump through all kinds of
hoops trying to keep track of when and if it needs to change the value
of AP. Also, selection between byte and word memory access is controlled
by bits in a "Data Pointer Control" (DPC) register. So, every time the
compiler
wants to emit code to access memory, it has to make sure the needed bits
in the DPC register are in the correct state.  The AP can be worked around,
but this DPC business is going to be really painful to deal with efficiently.

The MAXQ hardware stack has a minimum size of 16 words, so any C compiler
is going to have to use a software stack, presumably using the base
pointer + offset addressing mode. Also, push and pop are not available
for saving/restoring registers, because they only work in the hardware
stack. Also, the base pointer + offset addressing mode is advertised
as doing an unsigned add, so I presume it will not work for negative
offsets from the frame pointer, which would be useful for accessing arguments
on the stack.

The MAXQ looks good doing the dinky little "benchmarks" being offered
up.
And it may be good for the assembler programmer. However, my initial
impression is that any speed advantage imparted by the single clock
cycle model is going to be dissipated rapidly because, for any
reasonably large chunk of C code, a MAXQ C compiler might to end up
generating more instructions than any msp430 C compiler would...

>
> 
> BTW, for anyone who somehow miraculously isn't yet on Maxim's
mailing 
> list, the PDF file discussing their new microcontrollers is here: 
> http://pdfserv.maxim-ic.com/en/ej/MER_3.pdf .  The architecture is 
> rather different than what I've seen in the past.
> 
> Realistically probably won't be available until next year, I 
> imagine.  
> 
> ---Joel
> 
> 

>> However, my initial impression is that any speed advantage
imparted by the 
single clock cycle model is going to be dissipated rapidly because, for any
reasonably large chunk of C code, a MAXQ C compiler might to end up
generating more instructions than any msp430 C compiler would... <<

Ah, well the easy way round that is to write in assembly language! 

<g, d & r>

Preston,

> Just had a peek at the MAXQ document you referred
us to.
> 
> In the MAXQ, there is the AP register, which selects which of the
> accumulator you can actually do things to. So a C code generator
> is either going to either just set the AP to a fixed value (and
> have one destination accumulator) or else jump through all kinds of
> hoops trying to keep track of when and if it needs to change the value
> of AP.

All 16 accumulators are directly addressable, e.g. A[15].  Why use AP?
Because of APC, that's why.  AP is set after using an explicit
accumulator, IIRC.

> Also, selection between byte and word memory
access is 
> controlled
> by bits in a "Data Pointer Control" (DPC) register. So, every 
> time the compiler
> wants to emit code to access memory, it has to make sure the 
> needed bits
> in the DPC register are in the correct state.

It ain't necessarily so.  But on the whole, yes, it is a bit of a gaffe.

> The MAXQ hardware stack has a minimum size of 16
words, so 
> any C compiler
> is going to have to use a software stack, presumably using the base
> pointer + offset addressing mode. Also, push and pop are not available
> for saving/restoring registers, because they only work in the hardware
> stack.

Single cycle push of A[4] to software stack: MOVE A[4], @--DP[0]

> Also, the base pointer + offset addressing mode is
advertised
> as doing an unsigned add, so I presume it will not work for negative
> offsets from the frame pointer, which would be useful for 
> accessing arguments
> on the stack.

But MSP430 compilers don't use negative offsets from the stack pointer,
Peseton, so why should it be any different for MAXQ?  Besides, didn't
you read about the prefix registers?  "Negatve" values can be
synthesized, in this case, with modulo-64K addressing and a prefix
instruction.

> The MAXQ looks good doing the dinky little
"benchmarks" being 
> offered up.
> And it may be good for the assembler programmer. However, my initial
> impression is that any speed advantage imparted by the single clock
> cycle model is going to be dissipated rapidly because, for any
> reasonably large chunk of C code, a MAXQ C compiler might to end up
> generating more instructions than any msp430 C compiler would...

Don't think so.  We'll see when the first compilers come out.

-- Paul.

At 08:57 AM 3/22/2004 +0000, Paul Curtis wrote:
>...
>Don't think so.  We'll see when the first compilers come out.

So are you going to be the first :-) or did they pay IAR bags of money too?



// richard (This email is for mailing lists. To reach me directly, please 
use richard@rich...) 

Heh :-)

> >Don't think so.  We'll see when the
first compilers come out.
>
> So are you going to be the first :-) or did they pay IAR bags of money
too?
>
>
>
> // richard (This email is for mailing lists. To reach me directly, please
> use richard@rich...)

IAR are an obvious parner for any new silicon vendor in the 8/16-bit
micro business.  I'm not going to have the first MAXQ compiler.  I do
have an interest in the MAXQ, but the MAXQ needs to be taken seriously
and have real sampling silicon before committing resources to it.

dsPIC30F looks interesting, says Michael.  Perhaps we do that next, who
knows?

-- Paul.

> -----Original Message-----
> From: microbit [mailto:microbit@micr...]
> Sent: 22 March 2004 09:16
> To: msp430@msp4...
> Subject: Re: [msp430] Re: Maxim MAXQ (Was PICs - why?! ...)
> 
> 
> Heh :-)
> 
> > >Don't think so.  We'll see when the first compilers come
out.
> >
> > So are you going to be the first :-) or did they pay IAR 
> bags of money
> too?
> >
> >
> >
> > // richard (This email is for mailing lists. To reach me 
> directly, please
> > use richard@rich...)
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com. Free s/h on orders $50 or more to the 
> US & Canada.
> http://www.c1tracking.com/l.asp?cidU11
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/CFFolB/TM
> --------------------------
> -------~->
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

> IAR are an obvious parner for any new silicon vendor in the 8/16-bit
> micro business.  I'm not going to have the
first MAXQ compiler.  I do
> have an interest in the MAXQ, but the MAXQ needs to be taken seriously
> and have real sampling silicon before committing resources to it.
>
> dsPIC30F looks interesting, says Michael.  Perhaps we do that next, who
> knows?
> -- Paul.

the FFT and F/IIR benchmarks looked promising, I have an application for a
SW
defined radio on VHF coming up.

-- Kris