![]() |
|
Endian swapping in QB64pe - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3) +---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10) +---- Thread: Endian swapping in QB64pe (/showthread.php?tid=3547) |
Endian swapping in QB64pe - tantalus - 03-22-2025 Both of these routines work if I implement them in C as an external library or use the bswap_32/bswap_64 libc functions. They also happen to work in other BASIC's like FreeBASIC, BBC BASIC (SDL & Windows) and even the 32bit routine works in GFA BASIC on the Atari ST. Looking at the CPP code QB64pe uses for _SHL/_SHR, it "should" work! Is it QB64pe or me? Code: (Select All)
RE: Endian swapping in QB64pe - Petr - 03-22-2025 I tried to figure it out. I tried replacing all the _SHL, _SHR, AND, _READBIT and _SETBIT functions and in the end I got the same thing as with these functions. So I'll summarize. It's a perfect job for headaches. You can even see smoke coming from the ear. Your program even caused snow to melt in my area. I really don't know what the problem is! Code: (Select All)
again the same bad result.... Conclusion: I really don't know! RE: Endian swapping in QB64pe - tantalus - 03-22-2025 @Petr, thanks for that. I can now claim back at least 50% of my sanity. ..... for the time being.
RE: Endian swapping in QB64pe - SMcNeill - 03-22-2025 I figure it's mainly missing the type symbols and screwing with you with that. Code: (Select All)
RE: Endian swapping in QB64pe - SMcNeill - 03-22-2025 For an explanation of the issue you're seeing, (so you can account for it elsewhere in your code), see this: Code: (Select All)
Notice how the &H value changes on you? That's because QB64 and basic back in the day, didn't have UNSIGNED values, and also because they wanted to save as much precious memory as possible. &HH was... an INTEGER, as there was no _BYTE type in QB45. Thus, it represented 255. &HHHH was... an INTEGER, as integers are 2 bytes and that was the smallest size that could represent those hex digits. As an integer, that made its value -1. &HHHHHHHH was... an LONG. 4 bytes to hold those 8 hex values. In a signed long, that also made the value -1. So.... when you AND a value with -1, is that AND with a long or an integer or ???? You run into issues. (As you both have noticed.) Solution? Take that ambiguity out of your &H type. IF &HFF is *supposed* to be a LONG, then mark it as one: &HFF& IF &HFF is *supposed* to be an _INTEGER64, then mark it as one: &HFF&& Those suffixes there on the end of that &H value is *essential* for what you're doing to work without issues for you. Else you're mixing integers with longs with int64s and... You get FEFOFLOPOP00PS RE: Endian swapping in QB64pe - tantalus - 03-22-2025 (03-22-2025, 03:25 PM)SMcNeill Wrote: I figure it's mainly missing the type symbols and screwing with you with that.Thanks @SMcNeil, but I see this as not really acceptable in a language where I have explicitly declared the variable type, and I would have used OPTION _EXPLICIT also to make sure all my variables were correctly type declared to then have to use type suffixes too. Too many unnecessary temporary variables also mixing unsigned and signed, although my code above uses 2, I only did that for clarity/sanity. My original code was a function that worked on the reference and passed that back. Is this a quirk/niggle of QB64pe that will stay? RE: Endian swapping in QB64pe - SMcNeill - 03-22-2025 See my post above yours. I believe you missed it as I posted the second post and you were probably typing your response. Basically it's an issue that goes back to QB45 days and us maintaining backwards compatibility for that old code. You just need to add the proper suffix to your &H values to make certain that they're the return value you expect and not something unexpected. And I'm not certain what you're talking about with temp variables mixing signed and unsigned? You can strip those out completely. Code: (Select All)
RE: Endian swapping in QB64pe - DSMan195276 - 03-22-2025 (03-22-2025, 03:47 PM)tantalus Wrote: Thanks @SMcNeil, but I see this as not really acceptable in a language where I have explicitly declared the variable type, and I would have used OPTION _EXPLICIT also to make sure all my variables were correctly type declared to then have to use type suffixes too.The problem is mixing the signed literals with the unsigned variables. `&HFF00` is a signed 16-bit integer, so it undergoes sign extension when AND'd with an unsigned 32-bit variable, turning it into `&HFFFFFF00`. If you specify the original as `&HFF00~%` (unsigned 16-bit integer) then the problem goes away since sign extension won't happen when the value gets promoted to 32-bit. The other confusing aspect is that the number of digits you specify doesn't determine the type, so `&HFF00` and `&H0000FF00` are both signed 16-bit integers, adding extra zeros doesn't make it into a 32-bit integer. `&H0000FF00` is thus really `&HFFFFFF00` if you treat it as a 32-bit integer. In other languages hex literals are usually unsigned so this doesn't come up when you use them, otherwise the rules regarding integer promotion and such are basically the same. As much as I'd like to change hex literals to be unsigned by default it can't be done without breaking a significant number of existing QBasic and QB64 programs so it's not happening. You can always add the type suffix to make the literal unsigned though. RE: Endian swapping in QB64pe - Petr - 03-22-2025 Oh, right! Damn, I didn't remember that before. Now I remember it, when I read it here, in the first draft of $Color:32 I saw these declarations with data types for constants. Well, at least I repeated the bit operations Thanks for the explanation. I hope I finally remember it.
|