XC16处理发现了缺陷

我发现了我认为XC16中的一个缺陷，或者更可能在XC16的优化器部分中处理了*PSVy*标记的常量。我现在没有几天的时间来尝试构建一个简化的程序来重新创建问题，但是我想我会在这里发布我所经历的，以防其他人遇到问题，或者如果有空闲时间的人想要尝试并重新创建它。我的项目构建在MPLAX3中。15与XC16 1.25为PIC24EP512GP204。在硬件上进行测试，而不是在模拟器上进行测试，但是如果我的猜测是正确的，那么在模拟器中它也会失败。我的项目有很多常量查找表，并且我接近它们的auto-psv空间的极限，因此决定移动一些较少使用的表来编译托管psv空间。我不介意为了访问这些表而管理额外PSV页面的编译器中涉及的额外代码的速度损失的表。我有一个表，其中包含一个图形，该图形在启动时在我的LCD上显示一次。当声明为：const无符号char djd_logo3[1100]={然后将其更改为：u psv_const无符号char_.((space(psv))djd_logo3[1100]={此时当调用使用该表的函数时，代码导致地址异常。我的第一个想法是，也许我的索引超出了界限，但是仔细的检查显示它总是在范围之内，并且地址陷阱是在它进入的第一个循环中发生的，而索引是零。我检查了映射文件，发现编译器把表放在代码空间的最顶端，而其他东西都在代码空间的底部。表的起始位置是一个4字节的边界，这意味着一个双字边界。所以应该很好。我的下一步是向声明中添加一个“对齐”属性。我添加了对齐（8192）。现在不再有地址陷阱，但是图形的图像是不正确的。前30或40个像素是错误的。我看了看地图，发现编译器现在将表向下移动到与下层代码空间中的其他常量和代码相同的区域，而不是在代码空间的顶部。然后我意识到可能发生的事情。使用这个表的代码是一个大的循环，它从该表中读取字节，然后将这些字节作为索引用于另一组颜色查找表，以获得要放到屏幕上的实际红色、绿色和蓝色值。这意味着，在循环中，代码不断地访问一个表，然后另一个表。第一个表是移动到空间（psv）的表，而另一个表（颜色查找表）仍然是空间中的常规常量部分（auto-psv）的一部分。因此，当编译器从一个表读取数据然后从另一个表读取数据时，它必须不断地在循环中切换PSV页。我猜想，编译器在PSV页之间的切换上搞砸了，在试图访问其中一个表时设置为错误的PSV页。因此，我的下一步是在函数开始时创建一个小循环，并将图形从psv空间表加载到RAM数组中，然后在大循环中使用RAM数组而不是图形表。这样，大循环从RAM查找中提取图像，然后通过颜色查找表将其转换。但不再需要在这个大循环中切换PSV页面，这就解决了问题。现在，图形加载罚款和查找颜色罚款，并显示在液晶显示器上罚款。然后，我返回并删除声明中的align属性，然后编译器又将表移回代码空间的顶部，一切仍然正常。我相信它工作得很好，因为它不再试图在大循环中的两个PSV页面之间来回快速切换。我怀疑优化器最终将更改PSV页面的代码移动到错误的位置，并且当它试图访问两个表中的一个表时，PSV页面实际上仍然为另一个PSV页面设置为另一个表。当一个表位于代码空间的顶部时，如果它试图根据它在不同PSV页面中的位置访问一个表，但是PSV页面实际设置在那里，那么我可以看到它最终超出界限并导致地址陷阱。同样地，一旦表在代码空间的较低位置被重新定位（在我添加align属性之后），所有地址都将是有效的，但是如果PSV页码设置错误，那么就不会指向正确的数据。因此，结果中没有地址陷阱，只有坏数据，这就是我屏幕上出现错误数据的原因。我怀疑这与优化器（我把它设置为级别1）没有将切换PSV页面的代码与从特定常数数组读取的代码一起保留有关。