TicTexpv "Address Error"

→ **MyCalcs** profile · by **bruno costa** » 21 Feb 2014, 11:53

@Lionel Debroux: The "Address Error" only occur when I have files suitable for Tictexpv...

When I dont have no files the program run fine saying that are no files to open.

Sometimes the program run with files to open other times crash....

Do you think that could be some specific files that made the program crash?

Thanks

→ **MyCalcs** profile · by **Lionel Debroux** » 21 Feb 2014, 13:46

Do you think that could be some specific files that made the program crash?

Yup, maybe, even though it was never reported before.
If you can isolate one, or several, files which trigger the wicked Address Error, could you send me that / those file(s), or attach it / them here to a new post ?
Thanks in advance.

→ **MyCalcs** profile · by **bruno costa** » 21 Feb 2014, 13:52

Yes, I could send to you.

Can you send me your email?

→ **MyCalcs** profile · by **Lionel Debroux** » 21 Feb 2014, 13:59

lionel underscore debroux yahoo fr, or attached to a post in this topic

→ **MyCalcs** profile · by **bruno costa** » 21 Feb 2014, 15:04

Hi,

The file is in attach.

→ **MyCalcs** profile · by **bruno costa** » 21 Feb 2014, 15:07

And this one too...

→ **MyCalcs** profile · by **Lionel Debroux** » 21 Feb 2014, 15:10

Alright, but much more than the input PDF files, I need the corresponding files produced by the conversion, the files suitable for the calculator, with a .89y, .9xy or .v2y extension

→ **MyCalcs** profile · by **bruno costa** » 21 Feb 2014, 15:20

This one here?

Already downloaded with mViewer GX Creator....

→ **MyCalcs** profile · by **Lionel Debroux** » 22 Feb 2014, 17:32

The combination of an odd number of lines, and an odd byte width, triggers Address Error when performing unaligned word reads. None of the example files provided alongside tictexpv tripped the viewer.

→ **MyCalcs** profile · by **Lionel Debroux** » 22 Feb 2014, 22:00

Attached is a new, lightly tested version (don't consider it official just yet), which fixes the problem.
This new version ends up being smaller than the previous one, thanks to a change in compilation options and several additional code optimizations. Several more bytes could be squeezed for the unaligned reads through a well-known ASM trick, but using it through inline ASM with C operands doesn't yield the result I'd expect, which means I'm not talking to the compiler correctly, and it's too late to debug that.