Forum > FPC development
TypeInfo() - what is it?
PascalDragon:
--- Quote from: beria on December 01, 2022, 11:17:38 am ---I would say that the safety of such an approach follows directly from the whole paradigm of the Pascal language with a pre-description of all types.... But the procedure below is not working yet because it generates unnecessary code...
--- End quote ---
“not working yet” and “generates unnecessary code” are two different points. The code will behave the same no matter if the compiler generates “unnecessary” code or not.
--- Quote from: beria on December 01, 2022, 11:17:38 am ---
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- procedure test41(a: ptrUint); inline; begin if TypeInfo(a) = TypeInfo(uint8) then Writeln('1') else if TypeInfo(a) = TypeInfo(uint16) then Writeln('2') else if TypeInfo(a) = TypeInfo(uint32) then Writeln('4') else if TypeInfo(a) = TypeInfo(uint64) then Writeln('8'); end;
--- End quote ---
I don't know whether this is what you desire, but this will only ever differ if you compile for different platforms. But in that case you could just as well use a type instead of the variable for TypeInfo and thus profit from the already available optimization.
--- Quote from: beria on December 01, 2022, 11:17:38 am ---ps: there is a hope in the near future to wait at least beta of new functionality, what with pleasure I will test in the real and working project? I don't think it will be very difficult because, at first glance, I just saw how TypeInfo is implemented in the source code of FPC, just there artificially limited functionality, as opposed to many other built-in compiler functions, which also return a constant.
--- End quote ---
The important part is to make sure that there really wouldn't be a corner case.
--- Quote from: beria on December 01, 2022, 11:17:38 am ---pps: and on a side note, is there any way for "{$mode objfpc}" to use the simpler and more obvious "generics" syntax from the Delphi compatibility relim, just that I don't use?
--- End quote ---
No, there is not. In the future there will likely be a modeswitch for that, but not until mode ObjFPC supports some features that it currently lacks that mode Delphi supports. Please note however that with the Delphi syntax currently you'll be less able to write complex expressions using inline specializations.
beria:
--- Quote from: PascalDragon on December 01, 2022, 10:09:56 pm ---
--- Quote from: beria on December 01, 2022, 11:17:38 am ---I would say that the safety of such an approach follows directly from the whole paradigm of the Pascal language with a pre-description of all types.... But the procedure below is not working yet because it generates unnecessary code...
--- End quote ---
“not working yet” and “generates unnecessary code” are two different points. The code will behave the same no matter if the compiler generates “unnecessary” code or not.
--- End quote ---
[/quote]
The problem is purely in the ultimate optimization. This is the code of an extremely complex and multiplatform telemetry data decoder, I optimized it to the limit, including assembler inserts where necessary, because it is called many millions of times in real time. So even a set of redundant and unoptimized constant comparison operations is, by measurements, up to minus 5% of performance. At the moment I have different procedures for all dimensions of integer arguments, for this reason, which is very confusing and complicated, but if everything will work as it should, they can be removed in one and universal, which code will be dynamically generated, depending on the type of application. Exactly the same thing I already did for the variant when the argument of the procedure is a constant. I used to have separate procedures for them too, but beautifully and stably working IsConstValue() helped me a lot. By the way, it would be very good to rewrite the Move procedure using it. So, I'm just for a large number of such procedures for the compiler itself, not for the language.
Right now I have something like:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- procedure Decoder(a: uint64); inline; procedure Decoder(a: uint32); inline; procedure Decoder(a: uint16); inline; procedure Decoder(a: uint8); inline;
...and having to make a mandatory type change for variables with a sign. It's very annoying...
Something like this...
marcov:
Do you actually have an example where it matters? Since the code you post will first typecast to ptruint, and only then get the typeinfo of ptruint.
beria:
--- Quote from: marcov on December 01, 2022, 11:22:23 pm ---Do you actually have an example where it matters? Since the code you post will first typecast to ptruint, and only then get the typeinfo of ptruint.
--- End quote ---
That's why I write that now it doesn't work and you have to do everything in other ways... But I want it to work like any other compiler function and to get dynamic branching within a procedure...
PascalDragon:
--- Quote from: beria on December 01, 2022, 11:09:58 pm ---
--- Quote from: PascalDragon on December 01, 2022, 10:09:56 pm ---
--- Quote from: beria on December 01, 2022, 11:17:38 am ---I would say that the safety of such an approach follows directly from the whole paradigm of the Pascal language with a pre-description of all types.... But the procedure below is not working yet because it generates unnecessary code...
--- End quote ---
“not working yet” and “generates unnecessary code” are two different points. The code will behave the same no matter if the compiler generates “unnecessary” code or not.
--- End quote ---
The problem is purely in the ultimate optimization. This is the code of an extremely complex and multiplatform telemetry data decoder, I optimized it to the limit, including assembler inserts where necessary, because it is called many millions of times in real time. So even a set of redundant and unoptimized constant comparison operations is, by measurements, up to minus 5% of performance. At the moment I have different procedures for all dimensions of integer arguments, for this reason, which is very confusing and complicated, but if everything will work as it should, they can be removed in one and universal, which code will be dynamically generated, depending on the type of application. Exactly the same thing I already did for the variant when the argument of the procedure is a constant. I used to have separate procedures for them too, but beautifully and stably working IsConstValue() helped me a lot. By the way, it would be very good to rewrite the Move procedure using it. So, I'm just for a large number of such procedures for the compiler itself, not for the language.
Right now I have something like:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- procedure Decoder(a: uint64); inline; procedure Decoder(a: uint32); inline; procedure Decoder(a: uint16); inline; procedure Decoder(a: uint8); inline;
...and having to make a mandatory type change for variables with a sign. It's very annoying...
Something like this...
--- End quote ---
I still don't get what you're trying to achieve. If you retrieve the type information from a PtrUInt parameter then it will always be PtrUInt. It won't change depending on what you pass in. For that you'd need to use generics which wouldn't be a runtime difference either.
And I also don't get your remark regarding Move.
Navigation
[0] Message Index
[#] Next page
[*] Previous page