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
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.
Cheers
Soma