Z-World Dynamic C conversion from v5.26 to v9.21

I've been hired to upgrade the processor code in the product line of
this company. The product uses older (and soon to be obsolete) Z-World
Core modules that use Dynamic C v5.26. The hardware is to be upgraded
to Rabbit 3000 Cores. Can anyone comment on what obstacles (if any)
will be encountered in converting to Dynamic C 9.21? Vernon.

On 17 Jul 2006 10:08:55 -0700, "vernonedavis@gmail.com"
<vernonedavis@gmail.com> wrote:

>I've been hired to upgrade the processor code in the product line of
>this company. The product uses older (and soon to be obsolete) Z-World
>Core modules that use Dynamic C v5.26. The hardware is to be upgraded
>to Rabbit 3000 Cores. Can anyone comment on what obstacles (if any)
>will be encountered in converting to Dynamic C 9.21? Vernon.

I suggest to join the Rabbit Semi yahoo group and ask the question
there again. The group is fairly active and people from Z-World as
well as Rabbit Semiconductor frequently answer questions.

http://groups.yahoo.com/group/rabbit-semi/

HTH

Markus

<vernonedavis@gmail.com> wrote in message 
news:1153156135.326532.131620@m79g2000cwm.googlegroups.com...
> I've been hired to upgrade the processor code in the product line of
> this company. The product uses older (and soon to be obsolete) Z-World
> Core modules that use Dynamic C v5.26. The hardware is to be upgraded
> to Rabbit 3000 Cores. Can anyone comment on what obstacles (if any)
> will be encountered in converting to Dynamic C 9.21? Vernon.

Short answer is: it depends.

Dynamic C is basically ANSI-C, with some quirks and a lot of system/utility 
calls. Some of the latter have been cleaned up and homogenised over the 
years, but older-style calls tend to still work.

If your code is mostly C, it should be fine. You've not said whether you 
make use of specific features of the older Rabbit module e.g. TCP/IP, serial 
ports etc etc. If you use these extensively, it would be wise to check the 
manual for newer usage. I'd guess, though, that it'll probably just 
compile - if not, it'll tell you why not.

Unless you're doing something really weird, it sounds like a fairly 
straightforward job.

Steve
http://www.fivetrees.com 

Steve at fivetrees wrote:
> Short answer is: it depends.

Totally.

> Dynamic C is basically ANSI-C, with some quirks and a lot of system/utility 
> calls. Some of the latter have been cleaned up and homogenised over the 
> years, but older-style calls tend to still work.

For me, Dynamic C feels more like really really quirky CP/M hack of K&R, 
although without a linker and with broken declarations.  But over the 
years the beast has moved closer to ANSI.  I'm told 10.x has real 
optimizations, but I haven't played with it or the Rabbit 4000 yet.

> Unless you're doing something really weird, it sounds like a fairly 
> straightforward job.

I can't remember the specific issues with the older Z180 compiler as 
compared to the 9.x Rabbit version.  But I imagine there will be changes 
in three areas: language issues, API issues, and runtime issues.

In the language, the default storage class for variables changes from 
'static' to 'auto' at some point.  Happily, there's something like a 
pragma to adjust the default.  I'm guessing the weirdness of their 
cooperative multitasking hasn't changed much, except to add some new 
features here and there.

Some of the library APIs have stayed the same over the years (serial 
ports) while others have evolved (digital IO with shadow registers).

The Rabbit runtime system has grown over the years, but I'm not sure if 
"Hello World" on 9.x leaves less root memory than 5.x.

The complexity of a conversion like this is bounded by the nature of the 
hardware and the limitations of Dynamic C itself.  The older hardware 
had limited memory so there can't be all that much code overall.  And 
without a linker, Dynamic C strongly encourages the programmer to have 
all of the code in one big file.

Kelly

On Wed, 19 Jul 2006 13:55:46 +0100 in comp.arch.embedded, "Steve at
fivetrees" <steve@NOSPAMTAfivetrees.com> wrote:

><vernonedavis@gmail.com> wrote in message 
>news:1153156135.326532.131620@m79g2000cwm.googlegroups.com...
>> I've been hired to upgrade the processor code in the product line of
>> this company. The product uses older (and soon to be obsolete) Z-World
>> Core modules that use Dynamic C v5.26. The hardware is to be upgraded
>> to Rabbit 3000 Cores. Can anyone comment on what obstacles (if any)
>> will be encountered in converting to Dynamic C 9.21? Vernon.
>
>Short answer is: it depends.

It always is.

>
>Dynamic C is basically ANSI-C, with some quirks and a lot of system/utility 

Errm.  I admit it's been some 5 years since I last used it, but IMHO,
"Dynamic  C is basically ANSI-C, with some quirks" in much the same
way that "Java is basically ANSI-C, with some extensions."  Some of
the syntax is superficially similar, but beyond that, you're on your
own.

Regards,
                                        -=Dave

-- 
Change is inevitable, progress is not.

What I've noticed, so far...

Hardware is the major change; Serial Ports, I/O, etc. Interrupt Vector
assigments changed. The rest compiles fine.

Does anybody have the Dynamic C manual for v5.26? Cannot find it
anywhere.

Thanks for all the input, Vernon.

"Dave Hansen" <iddw@hotmail.com> wrote in message 
news:utgsb2pusd70qv2fflafc0c9f4p04cph5b@4ax.com...
> On Wed, 19 Jul 2006 13:55:46 +0100 in comp.arch.embedded, "Steve at
> fivetrees" <steve@NOSPAMTAfivetrees.com> wrote:
>
>>
>>Dynamic C is basically ANSI-C, with some quirks and a lot of 
>>system/utility
>
> Errm.  I admit it's been some 5 years since I last used it, but IMHO,
> "Dynamic  C is basically ANSI-C, with some quirks" in much the same
> way that "Java is basically ANSI-C, with some extensions."  Some of
> the syntax is superficially similar, but beyond that, you're on your
> own.

Ok, so I over-simplified ;).

OTOH, it's getting better. A pure C program should compile just fine - 
admittedly after a few tweaks for weirdnesses e.g. initialising a local 
variable in a declaration is quite, quite different. But I've had good luck 
porting classic C stuff over without too much fuss.

Steve
http://www.fivetrees.com 

"Kelly Hall" <khall@acm.org> wrote in message 
news:51rvg.10106$2v.1967@newssvr25.news.prodigy.net...
> Steve at fivetrees wrote:
>> Short answer is: it depends.
>
> Totally.
>
>> Dynamic C is basically ANSI-C, with some quirks and a lot of 
>> system/utility calls. Some of the latter have been cleaned up and 
>> homogenised over the years, but older-style calls tend to still work.
>
> For me, Dynamic C feels more like really really quirky CP/M hack of K&R, 
> although without a linker and with broken declarations.  But over the 
> years the beast has moved closer to ANSI.  I'm told 10.x has real 
> optimizations, but I haven't played with it or the Rabbit 4000 yet.

I'm a relative newcomer to Dynamic C, but I've read the various notes about 
upgrades to the compiler. There are some aspects that are frustrating, but 
on the whole, it's a pretty good system.

>> Unless you're doing something really weird, it sounds like a fairly 
>> straightforward job.
>
> I can't remember the specific issues with the older Z180 compiler as 
> compared to the 9.x Rabbit version.  But I imagine there will be changes 
> in three areas: language issues, API issues, and runtime issues.
>
> In the language, the default storage class for variables changes from 
> 'static' to 'auto' at some point.  Happily, there's something like a 
> pragma to adjust the default.

Yep. I include the pragma for auto just to be on the safe side ;).

> I'm guessing the weirdness of their cooperative multitasking hasn't 
> changed much, except to add some new features here and there.

I've avoided all those, since I have my own cooperative multitasker, and 
I've tried to stay with ANSI-C as far as possible in case this code ever 
needs to be ported to a different platform.

> Some of the library APIs have stayed the same over the years (serial 
> ports) while others have evolved (digital IO with shadow registers).

The TCP/IP stack seems to have evolved nicely too.

> The Rabbit runtime system has grown over the years, but I'm not sure if 
> "Hello World" on 9.x leaves less root memory than 5.x.

No idea. I did a tiny program to allow a serial number to be flashed to the 
User Block; it came in at around 40k with default compiler options. OTOH, my 
full-blown app, with TCP/IP, lots of serial port use, three command 
interpreters for the different interfaces etc etc etc, came in around 130k. 
It's not a million miles for the kind of code sizes I'd expect for my more 
usual platform (Renesas H8). Perhaps a tad bigger, probably due to the 
TCP/IP stack.

> The complexity of a conversion like this is bounded by the nature of the 
> hardware and the limitations of Dynamic C itself.  The older hardware had 
> limited memory so there can't be all that much code overall.  And without 
> a linker, Dynamic C strongly encourages the programmer to have all of the 
> code in one big file.

I struggled with that, since I'm a big decomposition/no 
globals/scope-limiting fiend. In the end I came up with a scheme more akin 
to normal linked-C-file usage, with one main and several .lib files. The 
only big difference was that the header section of each lib file contained 
the equivalent of a .h file. And yes, I realise it all gets compiled as one 
global block, but at least the code was a) nicely structured and b) portable 
without too much work.

Steve
http://www.fivetrees.com 

vernonedavis@gmail.com wrote:
> Does anybody have the Dynamic C manual for v5.26? Cannot find it
> anywhere.

The 6.x manual is online, and the 'New Features' section doesn't list 
much of significance.  I would think that it would be a good 5.x 
reference until you can find the real thing:

http://www.zworld.com/documentation/docs/manuals/DC32UsersManual/DC32TREF.pdf

Kelly

Kelly Hall wrote:
> The 6.x manual is online, and ....

THAT I had found. It appears that the syntax and keywords did not
change too much, so I can at least have a reference. Vernon.