Recent

Author Topic: Implicit converison, literals and QWORD variable warning  (Read 7076 times)

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #30 on: August 06, 2020, 01:28:01 pm »
Hi!

Yes - in Modula II you always had to typecast Cardinal <--> Integer.

I only wanted to point out that N. Wirth in Modula II had corrected his error.

Winni

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #31 on: August 06, 2020, 01:54:14 pm »
Circular reasoning. It is wrong because we assume it is wrong?

You are aware of technique called "Proof by contradiction" ?

Quote
Bingo, success!   C has postfix designations for literals to assign them the right type. Pascal does the same by a typecast that is also allowed in e.g. constant declarations.

Look these examples I posted in C and C++ and tell me what is the difference comparing to the same code with FPC.

Quote
So there is no way to have a negative number? How odd.

They have only signed numbers. My bad English (fixed). Anyone worked or studied JAVA know that weirdness.

Quote
And the hierarchy is clear in Pascal. The largest signed type is the top of the of all, and literals have the type, the corresponding unsigned type doesn't fit in its range so is orphaned.

How that can be? Signed type have 2nd complement N-1 bits mantissa (N bit, i.e. MBS is just a sign), while unsigned have N bits of mantissa? Let take a signed and unsigned 8-bit integer. What is on top 7 or 8 bit of mantissa? Or simply, what is higher 127 or 255?

If we stick on current logic for 64-bits with 64 bit CPUs, then this should be the case in FPC for 8-bit CPUs:

Code: Pascal  [Select][+][-]
  1.    if ($FF<0) then
  2.        writeln ("$FF literal is a negative number by FPC decision!")
  3.  

And it is not. Why again? Becuse it is wrong! Similar to 16, 32 and 64-bits CPUs and 128 in the future. Except now for current 64-bits CPUs is not the case. If you follow the logic, follow it consistently, always!

Warnings, as pointed in the firts post and Reply #5, are absolutely useless and the mess is to downgrade uint64 constant literals to int64. That is absolutely wrong.

Again, what is the case in Rio for the same 64-bit example code?
« Last Edit: August 06, 2020, 02:26:27 pm by process_1 »

FPK

  • Full Member
  • ***
  • Posts: 118
Re: Implicit converison, literals and QWORD variable warning
« Reply #32 on: August 06, 2020, 02:28:26 pm »

And it is not. Why again? Becuse it is wrong! Similar to 16, 32 and 64-bits CPUs and 128 in the future. Except now for current 64-bits CPUs is not the case. If you follow the logic, follow it consistently, always!

FPC is consistent, however consistency is not as simple as expected. Why? Because reality (hardware) is limited and CPUs cannot work with infinite large numbers. So constants out of the range of the largest signed type simple follow different rules.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #33 on: August 06, 2020, 02:39:34 pm »
Circular reasoning. It is wrong because we assume it is wrong?

You are aware of technique called "Proof by contradiction" ?

You are familiar with the term "gaslighting" ?

Quote
Quote
Bingo, success!   C has postfix designations for literals to assign them the right type. Pascal does the same by a typecast that is also allowed in e.g. constant declarations.

Look these examples I posted in C and C++ and tell me what is the difference comparing to the same code with FPC.

You post runtime results. These maybe implementation defined results, and thus not wholly standard C (and I know the standard of C++ even less)

Quote
Quote
So there is no way to have a negative number? How odd.

They have only signed numbers. My bad English (fixed). Anyone worked or studied JAVA know that weirdness.

Well basically that's what Pascal does too, but the unsigned types are basically predefined subranges + some compiler work to make it optimal. Or at least it was originally, things have gotten more complicated over the years.

Code: Pascal  [Select][+][-]
  1. type
  2.    WORD = 0..65535;

and all that. But the unsigned type corresponding to the highest type can't be defined in the straightforward way. That we still define it is a hack with pro and cons.

Quote
Quote
And the hierarchy is clear in Pascal. The largest signed type is the top of the of all, and literals have the type, the corresponding unsigned type doesn't fit in its range so is orphaned.

How that can be? Signed type have 2nd complement N-1 bits mantissa (N bit, i.e. MBS is just a sign), while unsigned have N bits of mantissa?

2-complement is not a hard requirement for Pascal. It is an implementation detail. And both types have the same range of values. Some are just 2^(n-1) lower than the other.

But the crucial principle is that an unsigned number can never be a superset of signed+unsigned numbers (since it can't contain the negative numbers), while a higher order signed number *can* be a superset of signed and unsigned values.


The typesystem equalizes both sides of the equation to the same type using type promotion rules to find the common subtype.
Quote
Let take a signed and unsigned 8-bit integer. What is on top 7 or 8 bit of mantissa? Or simply, what is higher 127 or 255?

A signed is always the highest value, so the signed type is on top. It has exactly the same range just shifted down. If you want full arithmetic for the unsigned 8-bit you need at least a 9-bit integer (which in practice becomes 16-bit).

Delphi 4 and higher provide a unsigned version of the highest integer type to be used as placeholder in headers. Its arithmetic is known flawed.

Quote
If we stick on current logic for 64-bits with 64 bit CPUs, then this should be the case in FPC for 8-bit CPUs:

Code: Pascal  [Select][+][-]
  1.    if ($FF<0) then
  2.        writeln ("$FF literal is a negative number by FPC decision!")
  3.  

It doesn't make sense, since you are comparing two types int8(0) and uint8(255) that don't have a common type, since that requires a 9-bit type for usual arithmetic due to type promotion rules.

Quote
Again, what is the case in Rio for the same 64-bit example code?

I don't know. Embarcadero is notoriously bad in publishing language rationales.  But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?
« Last Edit: August 06, 2020, 02:45:28 pm by marcov »

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #34 on: August 06, 2020, 03:05:15 pm »
You are familiar with the term "gaslighting" ?

The main problem is that you are so touchy that on anything wrote here you react as a childs. Gosh!

I point here on logical bug and probably Delphi incompatibility, suggesting to test and correct.

Quote
I don't know. Embarcadero is notoriously bad in publishing language rationales.  But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?

Exactly, you do not know, but stii claim that decision regarding this you have made is correct.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants

According to this, they didn't developed int128 type, but then again, I see logic why constant literals are probably not automatically converted to int64, as in FPC. I just asking confirmation from someone have Rio - I do not have it.


« Last Edit: August 06, 2020, 03:23:58 pm by process_1 »

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Implicit converison, literals and QWORD variable warning
« Reply #35 on: August 06, 2020, 03:25:36 pm »
I don't know. Embarcadero is notoriously bad in publishing language rationales.  But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?

Exactly, you do not know, but stii claim that decision regarding this you have made is correct.


Ironically, you don't know either (since you are seeking confirmation), but you are still certain that the decision is wrong.

One possible "solution" to this issue is to always ensure that there is some signed type that is the largest integer type available.   But it is not likely to be easy to implement this on all platforms.  (In fact, it may be non-trivial to create/implement this on *most* platforms)

In the meantime, the explicit casting does work, notwithstanding any aesthetic concerns.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #36 on: August 06, 2020, 03:41:13 pm »
The main problem is that you are so touchy that on anything wrote here you react as a childs. Gosh!

Try to discuss more rational and to the point, and you get less sentiment back.

Quote
I point here on logical bug and probably Delphi incompatibility, suggesting to test and correct.

I have now explained the design 5 times in various messages. If Delphi does it otherwise, it is either a new int128 type, or some hack.

In both cases to decide what is best, one would need very detailed analysis, since as said, these would be exceptions to the core type promotion rules. It doesn't matter that a few quick tests deliver results that you like at first glance, the core problem is divining the rules from the results.

If results are appealing for a few simple cases, but the rules suck, then this is not the way to go.

Things to try is testing on 32-bit windows ( I assume you mean 64-bit windows with your "64-bit", this might also differ), and testing with some qword and/or int64 typed variables instead of literals, testing if using hex notation matters.

It might be just a int128 emulation inside the compiler for literals only.

Quote
I don't know. Embarcadero is notoriously bad in publishing language rationales.  But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?

Exactly, you do not know, but stii claim that decision regarding this you have made is correct.

Correct would be having no uint64. But instead we have a dummy uint64. That is fine as long as you avoid mixing types (and better: limit the usage to a few cases like e.g. where filesystem API's specify qwords.)

Quote
http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants

According to this, they didn't developed int128 type, but then again, I see no logic why constant literals are probably not automatically converted to int64, as in FPC. I just asking confirmation from someone have Rio - I do not have it.

They don't say 64-bit only, so one must assume that they haven't. Or only emulate it inside the compiler's literal evaluation.

The only general fix is going to a full int128, the rest is just more hacks. That won't solve much, it just changes the windowdressing from one useless case to the next, and just adds more complex exceptions that can have strange combined effects (e.g. wrt overload selection).

But if you implement int128, a week later a patch for uint128 is implemented using the old hack, and the cycle starts up again.

« Last Edit: August 06, 2020, 03:43:31 pm by marcov »

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #37 on: August 06, 2020, 03:47:44 pm »
Ironically, you don't know either (since you are seeking confirmation), but you are still certain that the decision is wrong.

If FPC warning me that I need explicity to set uint64/QWord for constant literal to already variable declared as it, this cecrtainly have no sense.
And if uint64 literals are native types now, but automaticaly converted to signed value, that also have no sense.

The C/C++ code works correctly here, I have no doubt Rio works the same, as here is basic decision is quite clear. I will probably send tha quiterion to Embarcadero as I still have account from the last bought Delphi some 15 years ago. But, I doubt any answer will be taken here as vaild, as handy, FPC team deny any flaw in design here.

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #38 on: August 06, 2020, 03:57:31 pm »
Try to discuss more rational and to the point, and you get less sentiment back.

Sentiment back? That is how you call your infant reactions? I do not really know what else you expect.

All I wrote was with background and I find it was more than suitable and rational.

Though, I have nothing else to add. That is all.

 

TinyPortal © 2005-2018