User Activity

  • Posted a comment on ticket #2591 on Small Device C Compiler suite

    The same header files come with Simplicity Studio. But it seems only mcs51 is highly affected, so I can live with further restricting the use of this macro. But please at least mention its deprecation in the release notes.

  • Posted a comment on ticket #2605 on Small Device C Compiler suite

    AFAIK ds400 is a ds390 with some extra peripherals.

  • Posted a comment on ticket #2591 on Small Device C Compiler suite

    The old IDE can display multibyte variables in proper endianness, where Simplicity Studio cannot. And it can invoke SDCC which Studio can't. Of course changing one header file is much easier than all the rest that is required for suppoting SDCC. And any user could change the file as well. But this change is required by every user who downloads the files. And again after every update. And all this to please your feeling about standard compliance. And without warning of deprecation when building with...

  • Posted a comment on ticket #2591 on Small Device C Compiler suite

    I would not mind for this SDCC_PARMS_IN_BANK1 to be replaced by a standard-compliant one. I very much doubt anyone uses it. I even expect the whole option can be removed without anyone noticing.

  • Posted a comment on ticket #2602 on Small Device C Compiler suite

    Is it really too hard to type r9887 between brackets [r9887] instead?

  • Posted a comment on ticket #2591 on Small Device C Compiler suite

    I worked hard to get Silicon Labs to support SDCC in the past and managed to get them to deploy compiler independent header files by the use of this SDCC macro. In the meantime they changed their IDE to an Eclipse based one and it's once again Keil only. Can I assume that you will convince them to update their header files? Or can we expect this change to be the final push for them to abandon SDCC completely?

  • Posted a comment on ticket #2602 on Small Device C Compiler suite

    I expect (haven't checked) the cast to give higher register pressure than letting genPlus() do the sign extension. The downside could be that we can't do CSE on it. Laziness to implement something in all backends is hardly a good reason if there is efficiency to be gained. But for that we must first find out if it really is more efficient. I wonder how this fix affected Z80 code with its IX+<nn> access instructions. Isn't <nn> a signed char here?

  • Posted a comment on ticket #2591 on Small Device C Compiler suite

    Philipp, why are you so strong about removing this one important macro? This was the first macro to indicate the SDCC version to the code being compiled. There is a lot of code out there that depends on it. I suggest it to be reinserted. It already was only issued when sdcc extensions were enabled.

View All

Personal Data

Username:
maartenbrock
Joined:
2003-10-16 08:59:06
Location:
Tilburg / Netherlands / CEST
Gender:
Male

Projects

Skills

  • No skills entered.

Personal Tools

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks