IDE enhancements

[paradev]

Here a few ideas:

(1) Breakpoints. Display a list of all breakpoints with the ability to disable/enable some or all of them instead of deleting/recreating.

(2) Editor. It would be very useful to have a folding editor with a project explorer and to have a tabbed view of all open files (if wanted) instead of the randomly cascaded mess that exists at the moment.

(3) Running out of code space. It would be nice if the compiler could pretend that it has more memory available so that you can see how much past 512K your code has gone by. That way you would know if you can get things to fit by playing around with the userblock or wether it was totaly futile.

(4) Userblock. Add another tabbed page to the project-options box to enable easy modification of the userblock. EG. selecting type 2, 3 or 4. The Size and to then automatically adjust MAX_USERBLOCK_SIZE in the bios file.

Discuss :)

[IWriteCode]

Of you list, I like option 2 the best. A decent project manager, with also the possibility to run the current project, instead of the active file.

But what I would want most, is a decent, optimizing compiler, which generates hints and warnings, for things such as, unused variables, uninitialized variables, supicious code (like if ( i = 1) instead of ( i== 1)) etc.

[Rob]

I think Rabbit Semiconductor has done a great job with their processors and core modules. I especially like the familiarity of the Z80 based core. Their Dynamic 'C' IDE however leaves a lot to be desired. Although I agree that better support for projects, and other IDE enhancements would be nice, I personally am more concerned with the slightly brain dead, non ANSI C compiler.

This may not be the best forum for the following discussion but it is related.

The compiler manages to generate respectable code for initializing an int variable on the stack

ld hl, 0x0000 6
ld (sp + 0x00), hl 11

and even a global int.

ld hl, 0x0000 6
ld (0xB11F), hl 13

However, initializing a long on the stack is a little less respectable.

ld de, 0x0000 6
ld bc, 0x0000 6
ld h, b 2
ld l, c 2
ld (sp + 0x02), hl 11
ex de, hl 2
ld (sp + 0x00), hl 11
ex de, hl 2
----
42

It could be:

ld hl, 0x0000 6
ld (sp + 0x02), hl 11
ld hl, 0x0000 6
ld (sp + 0x00), hl 11
----
34

A 19% improvement and in this case easily optimized to:

ld hl, 0x0000 6
ld (sp + 0x02), hl 11
ld (sp + 0x00), hl 11
----
28 A 33% improvement.

It also gets it right when incrementing an int on the stack.

ld hl, (sp + 0x04) 9
inc hl 2
ld (sp + 0x04), hl 11
----
22

But the code generated for incrementing a long on the stack is dreadful!

ld hl, 0x0000 6
add hl, sp 2
ld e, (hl) 5
inc hl 2
ld d, (hl) 5
inc hl 2
ld c, (hl) 5
inc hl 2
ld b, (hl) 5
push bc 10
push de 10
ld de, 0x0001 6
ld bc, 0x0000 6
call L_add 12
ld h, b 2
ld l, c 2
ld (sp + 0x02), hl 11
ex de, hl 2
ld (sp + 0x00), hl 11
ex de, hl 2
----
108
And without showing the code for the subroutine L_add:
L_add 41
----
149 What the ...?!

This should be:

ld hl, (sp + 0x00) 9
ld de, 0x0001 6
add hl, de 2
ld (sp + 0x00), hl 11
ld hl, (sp + 0x02) 9
ld de, 0x0000 6
adc hl, de 4
ld (sp + 0x02), hl 11
----
58 A 61% improvement!

Even incrementing a long global variable is frieghtning.

ld de, (0xB11B) 13
ld bc, (0xB11D) 13
push bc 10
push de 10
ld de, 0x0001 6
ld bc, 0x0000 6
call L_add 12
ld (0xB11B), de 15
ld (0xB11D), bc 15
----
100
L_add 41
----
141

Again, this should be:

ld hl, (0xB11B) 11
ld de, 0x0001 6
add hl, de 2
ld (0xB11B), hl 13
ld hl, (0xB11D) 11
ld de, 0x0000 6
adc hl, de 4
ld (0xB11D), hl 13
----
66 A 53% improvement!

It's far more efficient, both in clock cycles and memory, to inline the long add than to set up parameters and call a subroutine.

These trivial examples show just how badly the Dynamic C compiler needs work. And this is without mentioning the bugs where it just plain gets it wrong.

In the mean time I would recommend the use of int datatypes where possible and only use long datatypes when absolutely necessary and even then consider using inline asm for inc/decrementing and simple arithmetic. I would also recommend writing all ISRs in assembly.

Perhaps Rabbit Semiconductor could put their efforts into a decent, stand-alone, ANSI C compiler and allow the IDE to become an open source project?
If not I just might be tempted to write my own. ;)

[AAL]

I couldn't agree more with Rob, nor could I put it more eloquently, given his examples.

I also am in agreement with IWriteCode in:
http://www.rabbitsemiconductor.com/forums/showthread.php?t=57

I am amazed by the amount of code that gets generated by DC. Correct complilation is not enough these days, it must also be efficient.

IMO they made the wrong move (probably for expediency) when they decided on DC. An ANSI compiler would open up rabbit to larger markets. There would be access to third party tool sets but still have access to Rabbit LIB's. competition is a good thing.
Just look at all the compilers for 8051, ARM, PIC etc.

I think this it one of the main weaknesses with Rabbit.

[KennyM]

I totally agree.
A decent GCC implementation would make it easy to target rabbit and ZWorld harware from any platform.

[jborge]

When every I go back to support code in Rabbit projects it is so painfull to use the IDE after using other compilers/editor IDE's .

Project manager, and tabbed editor would be a huge improvement, next to a debug window anchored on the right hand side of the IDE.

It is starting to worry me that the IDE is becoming so dated, and not much improvement has been done over the last couple of years.