• State Accepted Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 17 subscribers
  • Views 2554 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Force A51 to generate systematically LJMP.

Soma

I have a project under microvision 1, its A51, as the manual says, always generates LJMP code when the code address is a forward reference. I imported the project under microvision 3, and its A51 is more intelligent: it generates SJMP each time when possible. The problem is that the resulted .hex codes are different ... so I cannot use the newly generated code without excessive testing of the old application... Is there any way to force the more recent A51 assembers to systematically generate LJMP when they find a "jmp" in the source text ( even if it would be possible to use SJMP ) ?

Thanks and regards

Tibor

Parents
  • 0 in reply to Soma
    Soma said:
    if the generated code with uV3 is the same as it was with uV1, no reason to justify the change of the IDE

    Indeed, then there's no justification to change anything: not the tool, not the source code, not anything.  But I do assume that all this is in preparation of an actual change to the hexfile you want/need to make, right?  Because otherwise all this would be an exercise in futility.

    Soma said:
    On the other hand I could continue to work with Microvision 1, but the IDE is really old

    Being old is just a fact.  It's not a good reason to change things around, particularly not in a configuration-managed work environment.  Properly managed companies often keep entire development PCs stowed in a usable state, just fo the sake of avoiding this kind of headache.  In some fields of the profession, that is even required by law or typical contract.

    OTOH the IDE itself really is the least of your worries.  The only thing you really keep under full "configuration management" is the compiler (or assembler), linker and post-processing tools (hexfile generation, hexfile collation, ...).  Now, admittedly, he Keil '51 tools' command line syntax is weird enough that it may prove hard to convince modern IDEs to produce it.  But if all else fails (and given how fast machines are today, compared with what we had when uVision 1 was still available), one doesn't need fancy IDEs or even makefiles.  One can just write a batch file that just dumbly builds it all, every time.  Then you don't need an IDE at all; any usable programmers' editor should do.

    All that set aside: if you're talking about units produced in the high thousands, with quality assurance on your back, the price of getting an up-to-date PK51 licence to continue this work in a professional manner can't be prohibitive, can it?

    You could make the source changes while still using the old assembler, to demonstrate that these are indeed, effectively, no-op changes.  Then update the tool to see that there still is effectively no change, before embarking on the change you really want to do.

Reply
  • 0 in reply to Soma
    Soma said:
    if the generated code with uV3 is the same as it was with uV1, no reason to justify the change of the IDE

    Indeed, then there's no justification to change anything: not the tool, not the source code, not anything.  But I do assume that all this is in preparation of an actual change to the hexfile you want/need to make, right?  Because otherwise all this would be an exercise in futility.

    Soma said:
    On the other hand I could continue to work with Microvision 1, but the IDE is really old

    Being old is just a fact.  It's not a good reason to change things around, particularly not in a configuration-managed work environment.  Properly managed companies often keep entire development PCs stowed in a usable state, just fo the sake of avoiding this kind of headache.  In some fields of the profession, that is even required by law or typical contract.

    OTOH the IDE itself really is the least of your worries.  The only thing you really keep under full "configuration management" is the compiler (or assembler), linker and post-processing tools (hexfile generation, hexfile collation, ...).  Now, admittedly, he Keil '51 tools' command line syntax is weird enough that it may prove hard to convince modern IDEs to produce it.  But if all else fails (and given how fast machines are today, compared with what we had when uVision 1 was still available), one doesn't need fancy IDEs or even makefiles.  One can just write a batch file that just dumbly builds it all, every time.  Then you don't need an IDE at all; any usable programmers' editor should do.

    All that set aside: if you're talking about units produced in the high thousands, with quality assurance on your back, the price of getting an up-to-date PK51 licence to continue this work in a professional manner can't be prohibitive, can it?

    You could make the source changes while still using the old assembler, to demonstrate that these are indeed, effectively, no-op changes.  Then update the tool to see that there still is effectively no change, before embarking on the change you really want to do.

Children