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

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.

HTH

Markus

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

Totally.

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 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

It always is.

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

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.

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

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.

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

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.

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

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.

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

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:

Kelly

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.