Leon, you forget one thing.
You can define your own ISA (which is not trivial, by the way) but in the same time you have port at least an assembler.
In order to have an orthogonal instruction set you have to duplicate a lot of the hardware resources or to increase the pipeline.
And do not forget an long pipeline will allow you to increase the frequency but in same time the stall logic will be more complex as well. I don't want to think at data and structural hazards.

And I'm sure that after you'll implement this orthogonal instruction set you will discover that is not so much helpful because of the data dependencies.

>From my point a view an architecture with orthogonal ISA si no longer a RISC, it is a CISC and to enjoy the full flavor of this architecture an simple assembler and a simple port of the gcc is not enough because the compiler should generate out-of-order code in order to remove data dependencies and to reduce the penalties inserted by stall in pipe.

Best regards,
Adrian Popa

----- Original Message ----
From: Leon
To: m...
Sent: Monday, November 5, 2007 1:24:35 PM
Subject: Re: [msp430] Re: Reading a Flash byte

----- Original Message -----

From: "Paul Curtis"

To:

Sent: Monday, November 05, 2007 12:19 PM

Subject: RE: [msp430] Re: Reading a Flash byte

> Richard,

>

>> Hmm - I used to think that orthogonal = good .. but in fact you can get

>> a richer instruction set if it is NON orthogonal.

>

> Yeah, that's what we need, a nice rich instruction set... ;-)

>

>> I feel non-orthogonal instruction sets can aid compiler writers (Paul C

>> - jump in here!).

>

> There is no such thing as an orthogonal instruction set, every instruction

> set has aspects that make it non-orthogonal. The MSP430 is no exception,

> you can't mov.w @r4+, @r5+ for instance. The MSP430 instruction set is

> nice, the MSP430X instruction set is somewhat problematic. I don't think

> the AVR instruction set is particularly nice, I don't much like the many

> PIC

> architectures (including 24 and 33), and I don't very much like the MAXQ

> architecture. Of all these, MSP430 is by far the nicest but,

> unfortunately,

> it's also one of the "slowest" in number of clock cycles to run an

> instruction (let's not get into a debate about how much it can do.)

>

> I can't really pass comment on ARM as ARM has so many different

> instruction

> sets, but the original Arm instruction set was pretty awesome when it came

> out.

>

> I used to avidly follow the development of microprocessor and

> workstation- class processors, but of late that hobby has declined. There

> is

> very little new under the sun. The IntellaSys stuff, should it get going,

> looks interesting but I don't fancy the 18-bit CPU--why does Chuck design

> these things with wacky word sizes?

With FPGA kits available very cheaply with free tools, everyone can design

their own instruction set. 8-)

Leon

__________________________________________________

Beginning Microcontrollers with the MSP430

I find the datasheets from atmel to be more organized and clear than
TI. Just my opinion, perhaps this is why I find the MSP430 trickier,
but maybe "more tedious" would be putting it better.

--- In m..., Yuliyan Ivanov wrote:
>
> Dear Michael,
>
> Don't be so self-confident, you are missing a basic C knowledge.
You
> better take a friendly advice and read some good book on C. I'll
bet you
> can't say what will do the following C code:
>
> for( ; *p2; *p1++=*p2++ );
>
> Can you? And the MSP430 is not more trickier than any other micro
> controller, quite the contrary - it's very "C-friendly".
>
> Regards,
> Yuliyan
>
> mrobins99 wrote:
> > Apparently IAR has some built in functions to handle this.
> >
> > I found the folowing functions to get around this problem of the
> > limited pointer range.
> >
> > unsigned type __data20_read_type(unsigned long address);
> > void __data20_write_type(unsigned long address, unsigned type);
> >
> > I believe I have finished the bootloader portion. I will now
build
> > the application to send the .bin file to the uC using my defined
> > protocol.
> >
> > Thank you all for your help!
> >
> > ~1.5 work days to build a bootloader on a uC I have never used
> > before, not too bad I think!!! MPS430 is tricky compared to AVR!
> >
> > --- In m..., "old_cow_yellow"
> > wrote:
> >
> >> You seem to have more problems in c than its worth.
> >>
> >> If you want to learn c, why do you want to jump to Flash?
> >>
> >> A baseball player may occasionally use a bat to hit a fly or do
> >> needle work without taking off the glove.
> >>
> >> If you want to be a baseball player, learn how to hit and catch
> >> balls. Do not ask how to hit a fly or do embroidary.
> >>
> >> --- In m..., "mrobins99" wrote:
> >>
> >>> new problem:
> >>>
> >>> unsigned char *p, *q;
> >>>
> >>> p = (unsigned char*)(0x1F000);
> >>>
> >>> Warning[Pe1053]: conversion from integer to smaller pointer
> >>>
> >>> cannot be > 0x0FFFF, why is this> I have up to 0x1FFFF in
flash???
> >>>
> >>> --- In m..., Yuliyan Ivanov
wrote:
> >>>
> >>>> Dear Michael Robins,
> >>>> Obviously you need a good C book and some more diligence
> >>>>
> > reading
> >
> >> it.
> >>
> >>>> Regards,
> >>>> Yuliyan
> >>>>
> >>>> mrobins99 wrote:
> >>>>
> >>>>> --- In m..., "htrada2" wrote:
> >>>>>
> >>>>>
> >>>>>> Hi,
> >>>>>> it doesnt work because you ar casting to an (unsigned long).
> >>>>>> besides, why are you using an unsigned long pointer and then
> >>>>>>
> >>> asign
> >>>
> >>>>>> the value it points to an unsigned char??.
> >>>>>> I think you should have:
> >>>>>>
> >>>>>> unsigned char *p;
> >>>>>> unsigned char x;
> >>>>>>
> >>>>>> p = (unsigned char*)(0xFFFE);
> >>>>>> x = *p;
> >>>>>> txout(x);
> >>>>>> and then you could increment p.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --- In m..., "mrobins99"
> >>>>>>
> > wrote:
> >
> >>>>>>
> >>>>>>
> >>>>>>> --- In m..., "mrobins99"
> >>>>>>>
> >> wrote:
> >>
> >>>>>>>
> >>>>>>>
> >>>>>>>> I want to use a pointer to read the flash.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I have
> >>>>>>>> x = * (unsigned long*)0xFFFE;
> >>>>>>>> txout(x);
> >>>>>>>> which works okay!
> >>>>>>>>
> >>>>>>>> How can I use a pointer and increment it?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> I try this: not working!!!
> >>>>>>> Error[Pe513]: a value of type "unsigned long" cannot be
> >>>>>>>
> >>> assigned
> >>>
> >>>>>>>
> >>>>>>>
> >>>>> to
> >>>>>
> >>>>>
> >>>>>>> an entity of type "unsigned long *" C:\Michael
> >>>>>>> Robins\Work\END\Testing\Sample_Code\IAR\Bootloader\main.c
> >>>>>>>
> > 73
> >
> >>>>>>> unsigned long *p;
> >>>>>>> unsigned char x;
> >>>>>>>
> >>>>>>> p = (unsigned long)(0x0000FFFE);
> >>>>>>> x = * (unsigned long*)p;
> >>>>>>> txout(x);
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> okay it works, I had trouble thinking about it for a moment...
> >>>>>
> >>>>> unsigned char *p;
> >>>>>
> >>>>> p = (unsigned char*)(0xFFFE);
> >>>>> *p++;
> >>>>> txout(*p);
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> >
> >
>

for( ; *p2; *p1++=*p2++ );

I believe this will loop until the data which is pointed to by p2 is
equal to zero, and with each iteration the data that p1 is pointing
to is set equal to the data that p2 is pointing to, and then the
pointers are incremented by their respective data types. Perhaps this
can be used for copying a string?

Am I close?

--- In m..., "mrobins99" wrote:
>
> I find the datasheets from atmel to be more organized and clear
than
> TI. Just my opinion, perhaps this is why I find the MSP430
trickier,
> but maybe "more tedious" would be putting it better.
>
> --- In m..., Yuliyan Ivanov wrote:
> >
> > Dear Michael,
> >
> > Don't be so self-confident, you are missing a basic C knowledge.
> You
> > better take a friendly advice and read some good book on C. I'll
> bet you
> > can't say what will do the following C code:
> >
> > for( ; *p2; *p1++=*p2++ );
> >
> > Can you? And the MSP430 is not more trickier than any other micro
> > controller, quite the contrary - it's very "C-friendly".
> >
> > Regards,
> > Yuliyan
> >
> > mrobins99 wrote:
> > > Apparently IAR has some built in functions to handle this.
> > >
> > > I found the folowing functions to get around this problem of
the
> > > limited pointer range.
> > >
> > > unsigned type __data20_read_type(unsigned long address);
> > > void __data20_write_type(unsigned long address, unsigned type);
> > >
> > > I believe I have finished the bootloader portion. I will now
> build
> > > the application to send the .bin file to the uC using my
defined
> > > protocol.
> > >
> > > Thank you all for your help!
> > >
> > > ~1.5 work days to build a bootloader on a uC I have never used
> > > before, not too bad I think!!! MPS430 is tricky compared to AVR!
> > >
> > > --- In m..., "old_cow_yellow"

> > > wrote:
> > >
> > >> You seem to have more problems in c than its worth.
> > >>
> > >> If you want to learn c, why do you want to jump to Flash?
> > >>
> > >> A baseball player may occasionally use a bat to hit a fly or
do
> > >> needle work without taking off the glove.
> > >>
> > >> If you want to be a baseball player, learn how to hit and
catch
> > >> balls. Do not ask how to hit a fly or do embroidary.
> > >>
> > >> --- In m..., "mrobins99" wrote:
> > >>
> > >>> new problem:
> > >>>
> > >>> unsigned char *p, *q;
> > >>>
> > >>> p = (unsigned char*)(0x1F000);
> > >>>
> > >>> Warning[Pe1053]: conversion from integer to smaller pointer
> > >>>
> > >>> cannot be > 0x0FFFF, why is this> I have up to 0x1FFFF in
> flash???
> > >>>
> > >>> --- In m..., Yuliyan Ivanov
> wrote:
> > >>>
> > >>>> Dear Michael Robins,
> > >>>> Obviously you need a good C book and some more diligence
> > >>>>
> > > reading
> > >
> > >> it.
> > >>
> > >>>> Regards,
> > >>>> Yuliyan
> > >>>>
> > >>>> mrobins99 wrote:
> > >>>>
> > >>>>> --- In m..., "htrada2" wrote:
> > >>>>>
> > >>>>>
> > >>>>>> Hi,
> > >>>>>> it doesnt work because you ar casting to an (unsigned
long).
> > >>>>>> besides, why are you using an unsigned long pointer and
then
> > >>>>>>
> > >>> asign
> > >>>
> > >>>>>> the value it points to an unsigned char??.
> > >>>>>> I think you should have:
> > >>>>>>
> > >>>>>> unsigned char *p;
> > >>>>>> unsigned char x;
> > >>>>>>
> > >>>>>> p = (unsigned char*)(0xFFFE);
> > >>>>>> x = *p;
> > >>>>>> txout(x);
> > >>>>>> and then you could increment p.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --- In m..., "mrobins99"
> > >>>>>>
> > > wrote:
> > >
> > >>>>>>
> > >>>>>>
> > >>>>>>> --- In m..., "mrobins99"
> > >>>>>>>
> > >> wrote:
> > >>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> I want to use a pointer to read the flash.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> I have
> > >>>>>>>> x = * (unsigned long*)0xFFFE;
> > >>>>>>>> txout(x);
> > >>>>>>>> which works okay!
> > >>>>>>>>
> > >>>>>>>> How can I use a pointer and increment it?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>> I try this: not working!!!
> > >>>>>>> Error[Pe513]: a value of type "unsigned long" cannot be
> > >>>>>>>
> > >>> assigned
> > >>>
> > >>>>>>>
> > >>>>>>>
> > >>>>> to
> > >>>>>
> > >>>>>
> > >>>>>>> an entity of type "unsigned long *" C:\Michael
> > >>>>>>> Robins\Work\END\Testing\Sample_Code\IAR\Bootloader\main.c
> > >>>>>>>
> > > 73
> > >
> > >>>>>>> unsigned long *p;
> > >>>>>>> unsigned char x;
> > >>>>>>>
> > >>>>>>> p = (unsigned long)(0x0000FFFE);
> > >>>>>>> x = * (unsigned long*)p;
> > >>>>>>> txout(x);
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>> okay it works, I had trouble thinking about it for a
moment...
> > >>>>>
> > >>>>> unsigned char *p;
> > >>>>>
> > >>>>> p = (unsigned char*)(0xFFFE);
> > >>>>> *p++;
> > >>>>> txout(*p);
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >
> > >
> > >
> > >
>

>> and fully orthogonal

Hmm - I used to think that orthogonal = good .. but in fact you can get a
richer instruction set if it is NON orthogonal.

I feel non-orthogonal instruction sets can aid compiler writers (Paul C -
jump in here!).

They can also provide various useful opcodes for the advanced assembly
programmer.

----- Original Message -----
From: "Paul Curtis"
To:
Sent: Monday, November 05, 2007 12:19 PM
Subject: RE: [msp430] Re: Reading a Flash byte
> Richard,
>
>> Hmm - I used to think that orthogonal = good .. but in fact you can get
>> a richer instruction set if it is NON orthogonal.
>
> Yeah, that's what we need, a nice rich instruction set... ;-)
>
>> I feel non-orthogonal instruction sets can aid compiler writers (Paul C
>> - jump in here!).
>
> There is no such thing as an orthogonal instruction set, every instruction
> set has aspects that make it non-orthogonal. The MSP430 is no exception,
> you can't mov.w @r4+, @r5+ for instance. The MSP430 instruction set is
> nice, the MSP430X instruction set is somewhat problematic. I don't think
> the AVR instruction set is particularly nice, I don't much like the many
> PIC
> architectures (including 24 and 33), and I don't very much like the MAXQ
> architecture. Of all these, MSP430 is by far the nicest but,
> unfortunately,
> it's also one of the "slowest" in number of clock cycles to run an
> instruction (let's not get into a debate about how much it can do.)
>
> I can't really pass comment on ARM as ARM has so many different
> instruction
> sets, but the original Arm instruction set was pretty awesome when it came
> out.
>
> I used to avidly follow the development of microprocessor and
> workstation-class processors, but of late that hobby has declined. There
> is
> very little new under the sun. The IntellaSys stuff, should it get going,
> looks interesting but I don't fancy the 18-bit CPU--why does Chuck design
> these things with wacky word sizes?

With FPGA kits available very cheaply with free tools, everyone can design
their own instruction set. 8-)

Leon

> It's "Deja vu all over again" as Yogi would say. I still remember the
> old days when there was some i8080+6 parts lurking around with their
> "tiny","small","compact","large" and "huge" C memory models. But the
> things seems to be different now - no "position-independent" code
> benefits as with i8086, same data/model/attribute confusion... What do
> you think?

Hi Yuliyan!

For me, and for most other embedded developers, it's not "deja vu",
since we've been living in this world all along. In fact, MSP430 has
been the one-off since the traditional 64KB processor has really well
designed and fully orthogonal, so there have been no need for data
models etc.

With the introduction of MSP430X, the processor landed in the same
category as most other embedded processors; if you really need to get
most out of the hardware you have to specify more than you need to do on
a normal full-size processor.

For me, as a tools developer, it's a challenge to design the memory
types (__data16, __data20 etc.) and the memory models ("small", "medium"
etc.) so that the average customer should be able to get their
application up and running as easily as possible.

Who knows what the future will look like? If the embedded market should
go in the same direction as the desktop, i.e. getting rid of all this
data model soup, I believe that the processors need to be getting much
more powerful, so that it's ok to sacrifice resources (code space, ram
usage, clock cycles, power consumption etc.) for simplicity. But until
we get there, well, I believe that we have to live with it...

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Hello Anders,

It's "Deja vu all over again" as Yogi would say. I still remember the
old days when there was some i8080+6 parts lurking around with their
"tiny","small","compact","large" and "huge" C memory models. But the
things seems to be different now - no "position-independent" code
benefits as with i8086, same data/model/attribute confusion... What do
you think?

Best regards,
Yuliyan

Anders Lindgren wrote:
> mrobins99 wrote:
>
>
>> new problem:
>>
>> unsigned char *p, *q;
>>
>> p = (unsigned char*)(0x1F000);
>>
>> Warning[Pe1053]: conversion from integer to smaller pointer
>>
>> cannot be > 0x0FFFF, why is this> I have up to 0x1FFFF in flash???
>>
>
> Welcome to MSP430X!
>
> The background is that the traditional MSP430 is a traditional 16 bit
> processor. The first version of our tools to support MSP430X, V3.xx,
> only supported code in high memory. To access data you have to use
> built-in intrinsic functions that use an "unsigned long" to represent
> the address to access.
>
> In the new compiler, V4.xx, we have two modes om operation. In the
> "small" data model the world is exactly as in V3.xx. However, in the
> "medium" and "large" models we have introduced "data 20" memory. You can
> use the __data20 keyword to place variables, or make pointer point to,
> the high memory.
>
> Unfortunately, this comes with a price. In the "medium" and "large"
> memory model, all functions must save and restore the full 20 bit of the
> permanent registers, which require lightly more stack space
>
> Oh, by the way, I strongly recommend using "medium" over "large", since,
> in "medium", the default memory is the traditional 64KB memory.
>
> For example, when using "medium" data model, you can express your
> problem like:
>
> unsigned char __data20 * p;
>
> p = (unsigned char __data20 *)(0x1F000);
> -- Anders Lindgren, IAR Systems
>

mrobins99 wrote:

> new problem:
>
> unsigned char *p, *q;
>
> p = (unsigned char*)(0x1F000);
>
> Warning[Pe1053]: conversion from integer to smaller pointer
>
> cannot be > 0x0FFFF, why is this> I have up to 0x1FFFF in flash???

Welcome to MSP430X!

The background is that the traditional MSP430 is a traditional 16 bit
processor. The first version of our tools to support MSP430X, V3.xx,
only supported code in high memory. To access data you have to use
built-in intrinsic functions that use an "unsigned long" to represent
the address to access.

In the new compiler, V4.xx, we have two modes om operation. In the
"small" data model the world is exactly as in V3.xx. However, in the
"medium" and "large" models we have introduced "data 20" memory. You can
use the __data20 keyword to place variables, or make pointer point to,
the high memory.

Unfortunately, this comes with a price. In the "medium" and "large"
memory model, all functions must save and restore the full 20 bit of the
permanent registers, which require lightly more stack space

Oh, by the way, I strongly recommend using "medium" over "large", since,
in "medium", the default memory is the traditional 64KB memory.

For example, when using "medium" data model, you can express your
problem like:

unsigned char __data20 * p;

p = (unsigned char __data20 *)(0x1F000);
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

You seem to have more problems in c than its worth.

If you want to learn c, why do you want to jump to Flash?

A baseball player may occasionally use a bat to hit a fly or do
needle work without taking off the glove.

If you want to be a baseball player, learn how to hit and catch
balls. Do not ask how to hit a fly or do embroidary.

--- In m..., "mrobins99" wrote:
>
> new problem:
>
> unsigned char *p, *q;
>
> p = (unsigned char*)(0x1F000);
>
> Warning[Pe1053]: conversion from integer to smaller pointer
>
> cannot be > 0x0FFFF, why is this> I have up to 0x1FFFF in flash???
>
> --- In m..., Yuliyan Ivanov wrote:
> >
> > Dear Michael Robins,
> > Obviously you need a good C book and some more diligence reading
it.
> > Regards,
> > Yuliyan
> >
> > mrobins99 wrote:
> > > --- In m..., "htrada2" wrote:
> > >
> > >> Hi,
> > >> it doesnt work because you ar casting to an (unsigned long).
> > >> besides, why are you using an unsigned long pointer and then
> asign
> > >> the value it points to an unsigned char??.
> > >> I think you should have:
> > >>
> > >> unsigned char *p;
> > >> unsigned char x;
> > >>
> > >> p = (unsigned char*)(0xFFFE);
> > >> x = *p;
> > >> txout(x);
> > >> and then you could increment p.
> > >>
> > >>
> > >>
> > >> --- In m..., "mrobins99" wrote:
> > >>
> > >>> --- In m..., "mrobins99"
wrote:
> > >>>
> > >>>> I want to use a pointer to read the flash.
> > >>>>
> > >>>>
> > >>>> I have
> > >>>> x = * (unsigned long*)0xFFFE;
> > >>>> txout(x);
> > >>>> which works okay!
> > >>>>
> > >>>> How can I use a pointer and increment it?
> > >>>>
> > >>>>
> > >>> I try this: not working!!!
> > >>> Error[Pe513]: a value of type "unsigned long" cannot be
> assigned
> > >>>
> > > to
> > >
> > >>> an entity of type "unsigned long *" C:\Michael
> > >>> Robins\Work\END\Testing\Sample_Code\IAR\Bootloader\main.c 73
> > >>>
> > >>> unsigned long *p;
> > >>> unsigned char x;
> > >>>
> > >>> p = (unsigned long)(0x0000FFFE);
> > >>> x = * (unsigned long*)p;
> > >>> txout(x);
> > >>>
> > >>>
> > >
> > >
> > > okay it works, I had trouble thinking about it for a moment...
> > >
> > > unsigned char *p;
> > >
> > > p = (unsigned char*)(0xFFFE);
> > > *p++;
> > > txout(*p);
> > >
> > >
> > >
>

new problem:

unsigned char *p, *q;

p = (unsigned char*)(0x1F000);

Warning[Pe1053]: conversion from integer to smaller pointer

cannot be > 0x0FFFF, why is this> I have up to 0x1FFFF in flash???

--- In m..., Yuliyan Ivanov wrote:
>
> Dear Michael Robins,
> Obviously you need a good C book and some more diligence reading it.
> Regards,
> Yuliyan
>
> mrobins99 wrote:
> > --- In m..., "htrada2" wrote:
> >
> >> Hi,
> >> it doesnt work because you ar casting to an (unsigned long).
> >> besides, why are you using an unsigned long pointer and then
asign
> >> the value it points to an unsigned char??.
> >> I think you should have:
> >>
> >> unsigned char *p;
> >> unsigned char x;
> >>
> >> p = (unsigned char*)(0xFFFE);
> >> x = *p;
> >> txout(x);
> >> and then you could increment p.
> >>
> >>
> >>
> >> --- In m..., "mrobins99" wrote:
> >>
> >>> --- In m..., "mrobins99" wrote:
> >>>
> >>>> I want to use a pointer to read the flash.
> >>>>
> >>>>
> >>>> I have
> >>>> x = * (unsigned long*)0xFFFE;
> >>>> txout(x);
> >>>> which works okay!
> >>>>
> >>>> How can I use a pointer and increment it?
> >>>>
> >>>>
> >>> I try this: not working!!!
> >>> Error[Pe513]: a value of type "unsigned long" cannot be
assigned
> >>>
> > to
> >
> >>> an entity of type "unsigned long *" C:\Michael
> >>> Robins\Work\END\Testing\Sample_Code\IAR\Bootloader\main.c 73
> >>>
> >>> unsigned long *p;
> >>> unsigned char x;
> >>>
> >>> p = (unsigned long)(0x0000FFFE);
> >>> x = * (unsigned long*)p;
> >>> txout(x);
> >>>
> >>>
> >
> >
> > okay it works, I had trouble thinking about it for a moment...
> >
> > unsigned char *p;
> >
> > p = (unsigned char*)(0xFFFE);
> > *p++;
> > txout(*p);
> >
> >
>