Submitting changes to support Big Endian (z/Linux) platform

[MookThompson]

Hi,

I'm currently working on making tvision work an a Big Endian Linux platform (s/390 Linux aka z/Linux) - it's mostly working now. There are a number of changes required, but they're all fairly small and are under a CMake-detected -DTV_BIG_ENDIAN #define, so shouldn't affect normal Little Endian builds. I'm an experienced dev, but new to the GitHub collaboration process. What's the preferred way to submit my changes back to this project so others can benefit from them?

Thanks, Mark

[magiblot]

Hi, Mark!

First of all, let me express my gratitude for willing to get involved.

However, just yesterday I also began working on this and I was close to finishing. So I am worried that some of the effort you have put into this may have been in vain. But I am nonetheless interested in seeing what you did.

I guess the best way to share your changes is to use GitHub's pull request system. For this you have to:

1. Fork this repository (by clicking on the 'Fork' button visible in the project's homepage).
2. Commit your changes to the forked repository:
   • If you are familiar with Git:
     1. Clone your forked repository to your computer.
     2. Add your changes.
     3. Create a commit and push it.
   • If you prefer to do everything via the web UI:
     1. In your local filesystem, create a file hierarchy with just the files that had changes, keeping the original directory structure (e.g. CMakeLists.txt, include/tvision/system.h, include/tvision/scrncell.h...).
     2. Then go to the homepage of your forked repository and click "Add file" > "Upload files".
     3. From the file hierarchy with your changes, drag the root-level files and directories into the web page (e.g. CMakeLists.txt, include...).
     4. Once you are sure that you uploaded everything, click "Commit changes".
3. In your forked repository's homepage you will be then offered to open a pull request or at least to "Contribute changes", from where you will be able to submit a pull request.

Thank you very much!

[MookThompson]

Hi Magiblot,

No problem - thanks to you for all your hard work keeping a still very useful framework relevant.

I'll try to go down the Git route and see how I get on - it's a useful learning exercise.

It does now appear to be working for me (with the demos anyway). I've only made changes to address issues I've come across, so you may need to make the same fixes to other codepaths I've not hit. The fixes are broadly in 3 areas:

• use of memcpy to copy between char and integer types. In my PR, I created a 'tvintmemcpy', which #defines to the normal memcpy on LE platforms (so no runtime changes), but does a crude byte-reversed memcpy on BE ones. I then went through and changed any memcpy calls where one param is an integer pointer and the other is a char* to use this new tvintmemcpy. This issue affects TermColor::operator= and TermColor::operator uint32_t, CpTranslator::toPackedUtf8, utf32To8, TCellChar::moveInt, and the struct colorconv_r::colorconv_r(TermColor aColor...) constructor. string_as_int has a similar issue, but I've had to address it slightly differently. I've noticed that platform/far2l.cpp seems to have 12 memcpy calls which look like they would need to also be replaced by tvintmemcpy, but I'm unable to test this so haven't made these changes.
• the optimisation of fast_btoa, as the comment says, is only suitable for LE platforms as the btoa_lut_elem_t is a compound struct (3 chars and a uint8). In my PR, I've provided a non-optimised version under the BE #define, which also (probably unnecessarily) null-terminates the destination buffer.
• The struct KeyDownEvent relies on a union of ushort and CharScanType types, but the order of the elements of the CharScanType are reversed on BE platforms. To minimise the diff, I've just reversed the order of the charCode and scanCode members of the struct CharScanType under the TV_BIG_ENDIAN define.

Hope this helps. I'll hopefully get the PR sorted today. Mark