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
Well, thanks for the sympathizing note: although I mostly agree with you, in the context I have also some understanding of the reasons: where there is a fleet of a few hundredths & thousands machines out in the world, you don't really want to risk recalling them. As the original works were written in assembly, I personally also fear that replacing LJMPs with SJMP changes the timing of the system... so avoid these changes and the associated administrative and testing work is part of my objectives.
On the other hand if the generated code with uV3 is the same as it was with uV1, no reason to justify the change of the IDE..On the other hand I could continue to work with Microvision 1, but the IDE is really old... I also envisaged to carry the full project under VSCode or similar ( e.g. SublimeText ), keeping the building tools from Microvision 1... but haven't tested it ( yet :-) ). So finally I think I'll follow your advice, take the listing files and modify the "jmp" and "call" text in the source to "ljmp" and "lcall" wherever necessary.
Cheers
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.
thanks again for your note: meanwhile I changed all the necessary "jmp" instructions to "ljmp" ( by comparing the .lst files, I could identify where the modification was necessary ), assembled the sources... and the result is really interesting: I have exactly the same length of code, data, idata and xdata segments, with the same names... but mapped / loacated in a different manner ... resulting in different .hex files as output. The linker order in the two projects ( the .prj file for uVision1 and the .uv2 file for uVision3 ) is the same - this can be verified on the header of the .M51 files - but the segment order is different: frankly speaking, I have no idea why ... and I decided not to go further: I simply give it up: I spent a little bit more than 2 days to find it out, until now it was interesting and challenging... but now it became simply annoying ( and futile, as you said ). As you noticed, I can use any editor to work comfortably with the source files, and still use the old building tools - meeting the project and process requirements as well.
Some additional notes:
1. Getting a recent PK51 license would not help: I already have to run uVision1 and 3 on an XP Virtual Machine, as the building tools does not run on my 64-bit Win10 PC... and I guess that the latest PK51 buiding tool, similarly to uVision3, would neither give the same output than uVision1
2. We also keep some old OSs ( e.g. WinXP ) running on real- and/or virtual machines, with the required HW/SW tools ( old IDEs, JTAG probes, etc... ) in order to be able to maintain our old products.
3/ Finally budget: yes, getting the up-to-date PK51 license could be done - if it would be justified... but in this case, it is not.