XC8 1.45 vs XC8 1.42代码不起作用？

什么是“锁定我们的图片”的问题？汇编代码的比较可能会启发某人。-没有详细、精确的描述，就不可能决定问题是在编译器端还是最终在源代码侧（例如，丢失或不影响代码执行的易失性属性）。



      以下为原文

    What is "the issue that locks our PIC" ?
A comparison of the assembler code generated might enlighten somebody. - - - Without a detailed, precise description it is impossible to decide whether the problem is on the compiler side or eventually on the source code side (such as e.g. a missing volatile attribute that might or might not affect code execution).

未知的。



      以下为原文

    Unknown.

HI，简单规则：如果使用另一个编译器，生成的ASM代码将在99%的情况下是不同的。如果一个特定的编译器版本生成不再工作的代码，那么您需要再次验证它。它可能是一个代码变小/更大，然后是看门狗。可能是编译器对代码/变量进行了不同的定位，因为项目没有适当地初始化变量或任何东西，而且出错了。因此，底线意味着代码中仍然存在一些问题，并且应该用最新版本再次调试它（您可以）。通常假设它有更少的bug，但是生成的代码本身可能更小或更大。该项目应该运行，如果它没有优化（假设非优化版本运行）。



      以下为原文

    Hi,
Simple rule : if another compiler is used, the generated  ASM code will in 99% of the cases be different.
If one specific compiler version generates codes that does not work anymore then you need to validate it again.
It could be that one piece of code becomes smaller / larger and then watchdog was at the border.
It could be that the compiler locates the code / variables differently and as the project does not initialize properly variables or whatever and something goes wrong.
So bottom line it means some issue remains in the code and you should debug it again with the latest version (you can generally always assume that it has less bugs but generated code itself could be smaller or...larger.
Regards
PS : if you have the PRO version I suggest you compile your code in PRO mode...this is a good test about proper code and initializations. the project should operate as if it was not optimized (assuming the non optimized version runs).
 
 

如果你的代码在V1.42工作，那么每个人都应该使用它。您可以在同一台计算机上安装许多版本。如果您想使用V1.45，那么您需要提供比“我的代码不工作”更多的信息。您认为有一些问题会阻止所有代码工作吗？他们没有注意到？找出它为什么不起作用的原因。



      以下为原文

    IF your Code works on V1.42 Then everyone should use that. You can install many versions on the same computer.
If you want to use V1.45 then You need to provide more information than " My Code Does Not Work" You think there is some issue that stops all code from working? That they did not notice?
Find out exactly why it does not work.

是什么促使了新编译器的改变？



      以下为原文

    What prompted the change to the new compiler?

感谢所有的反馈和建议。我们不会花时间调试这些问题，因为旧的编译器工作，还有其他的力量在工作，但现在不是一个选项。“锁定PIC”的问题将需要调试时间，或者有人写了编译器的更改来给我们应该注意的领域提供建议，打开编译器输出的调试是不会发生的，我们没有时间。我很高兴现在是公开的，一个未知的问题是痛苦的。处理。我们没有专业版，这是不可能发生调试这个问题。我们已经安装了旧的编译器在每台计算机上，我们不相信这将是一个问题，但它显然是。对新编译器的更改没有被提示，它是“嘿新雇用，GO获得XC8”添加到“不相信这将是一个问题”，所以没有指定。XC8版本现在被指定为新租用安装，希望我能提供更多帮助。谢谢大家的建议和支持。



      以下为原文

    Thanks for all the feedback and advice. 
 
We're not going to spend the time to debug the issues since the old compiler works, there are other forces at work but it's not an option right now. "The issue that locks our PIC" would require the debug time, or someone who wrote the changes to the compiler to give advice as to areas that we should look at, open debugging of compiler output isn't going to happen we don't have the time.
 
I'm glad it's now public now, an unknown issue is a pain to deal with.
 
We do not have the PRO version and that is not likely to happen to debug this issue.
 
We have installed the old compiler on every computer now, we did not believe it would be an issue but it clearly is.  The change to the new compiler was not prompted, it was "Hey new hire, go get XC8" added to the "not believing it would be an issue" so none was specified. XC8 version is now specified for new hire installation.
 
I wish I could be more help. Thanks for the advice and the support @community.

感谢所有的反馈和建议。我们不会花时间调试这些问题，因为旧的编译器工作，还有其他的力量在工作，但现在不是一个选项。“锁定PIC”的问题将需要调试时间，或者有人写了编译器的更改来给我们应该注意的领域提供建议，打开编译器输出的调试是不会发生的，我们没有时间。我很高兴现在是公开的，一个未知的问题是痛苦的。处理。我们没有专业版，这是不可能发生调试这个问题。我们已经安装了旧的编译器在每台计算机上，我们不相信这将是一个问题，但它显然是。对新编译器的更改没有被提示，它是“嘿新雇用，GO获得XC8”添加到“不相信这将是一个问题”，所以没有指定。XC8版本现在被指定为新租用安装，希望我能提供更多帮助。谢谢大家的建议和支持。



      以下为原文

    Thanks for all the feedback and advice. 
 
We're not going to spend the time to debug the issues since the old compiler works, there are other forces at work but it's not an option right now. "The issue that locks our PIC" would require the debug time, or someone who wrote the changes to the compiler to give advice as to areas that we should look at, open debugging of compiler output isn't going to happen we don't have the time.
 
I'm glad it's now public now, an unknown issue is a pain to deal with.
 
We do not have the PRO version and that is not likely to happen to debug this issue.
 
We have installed the old compiler on every computer now, we did not believe it would be an issue but it clearly is.  The change to the new compiler was not prompted, it was "Hey new hire, go get XC8" added to the "not believing it would be an issue" so none was specified. XC8 version is now specified for new hire installation.
 
I wish I could be more help. Thanks for the advice and the support @community.

我怀疑原因是他们改变了V1.42中的“短长”类型，就是这样。在V1.42中，短长型从24位变为32位，并且去除了因特24t和uTn24.t类型。在V1.43中，它们恢复了旧的行为（谢天谢地，因为我在某些项目中使用UTIN 24t T，这在V1.42上不能正确地进行）。此外，因为我用尽可能少的RAM，通过手动放置一些变量），从我能看到的情况下，编译器在可能的情况下在内部使用短长类型，例如在乘法期间…这样做将使用一个24位结果（8×16）与V1.41，V1.43等的AlgRyththm，一个带有32位结果（16×16）的AlgRyththm，带有V1.42的底线，如果用V1.41工作的代码，不能与V1.42一起工作，但将与V1.43一起使用。



      以下为原文

    I Suspect the cause was that they changed the "short long" type in v1.42, that's it. in v1.42 the short-long type went from being 24 bits to 32 bits and the int24_t and uint24_t types were removed.
 
In v1.43 they restored the old behaviour (thankfully, as i used uint24_t in some projects that would not excecute correctly on v1.42. Also because i used as little ram as possible, with manual placement of some variables)
 
From what i was able to see, the compiler uses the short long type internally when possible, for example during multiplications... doing something like this
uint16_t varA = ...;
 
uint8_t varB = ...;
 
 
 
uint16_t varC = varA * varB;
 
uint32_t varD = varA * varB;
would use an algorythm with 24 bit result (8 * 16) with v1.41, v1.43 etc and an algorythm with 32bit result (16 * 16) with v1.42
 
Bottom line, if code worked with v1.41, could not work with v1.42 but would with v1.43

哦，如果短裤在1.42到1.45之间变化，那就可以解释为什么东西在1.42工作，而不是其他版本很好地知道我们的代码库。



      以下为原文

   


Oh, if shorts changed between 1.42 to something else in 1.45, that would explain why are stuff works in 1.42 and not other versions quite nicely knowing our code base.

我注意到这些变化在编译器安装DIR中的文件中。



      以下为原文

    I note these kinds of changes are in the  file in the compiler install dir.

我想他们做到了。



      以下为原文

   
I think they did

每一个新的更新我都阅读了变更日志，如果我没有更新一段时间，我读了什么是新的章节。无论如何，从32位到24位的变化对于许多操作可能是代码更小的原因，我记得甚至不能编译一个项目，因为内存不足。你的程序不再工作了，我不知道，但是如果你想更新，这是一个开始的地方。否则，只需安装编译器的两个版本。对于经常不更新的项目，我总是保留不止一个。



      以下为原文

    Every new update i read the changelog, if i haven't updated in a while i read the what's new section.
 
anyway the change from 32 bit to 24 bit for many operations is probably the reason why the code was much smaller, i remember not even being able to compile a project because of insufficient memory.
 
Why your program doesn't work anymore i have no idea, but that's a place to start IF you will ever want to update.
Otherwise, just keep installed the two versions of the compiler. I always keep more than one, for projects that are not updated frequently

当然，在1.42中，It24类型关键词不适当地消失，在1.43恢复，但是短的长类型从来没有故意地或无意地宽32位。



      以下为原文

   
Certainly the int24 type keywords disappeared inappropriately in 1.42, to be reinstated in 1.43, but the short long types have never been 32 bits wide, either intentionally or unintentionally.
 
Jeff.