Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On 2017-04-22 16:29, Jon Foster wrote: > I was surprised to read integer is always 32bit. I > expected it to be Int64 on 64bit platforms. Yes, Object Pascal's types are a nightmare. An insane amount of types and inconsistencies. That goes for base types and string types. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Saturday 22 April 2017 17:29:07 Jon Foster wrote: > On 04/22/2017 03:18 AM, Martin Schreiber wrote: > > On Saturday 22 April 2017 11:48:46 Graeme Geldenhuys wrote: > >> On 2017-04-22 10:37, Graeme Geldenhuys wrote: > >>> for the life of me I can't find that post. > >> > >> Saying that, I did track down the Delphi blog post that sparked the > >> conversation on Google+ I'm looking for. > >> > >> https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/bl > >>og/ 2017-february-delphi-linux-compiler.html > > > > MSElang/MSEpas does not use basic datatypes with variable size. MSEpas > > has int8, int16, int32, int64, card8, card16, card32 and card64 which can > > be mapped to the traditional pascal type names as you like. > > > > Martin > > Considering how many different architectures out there it is probably a > wise choice to name types by size. I would. :-) Or maybe just two generic > names followed by a bit size modifier like with C structures. That way you > could use a 4 bit unsigned int where ever it might be convenient... not > just in structures. The developer could "type" them too for type safety > (type nibble = unsigned:4;). > That's the case for MSElang please see the Wiki: https://gitlab.com/mseide-msegui/mselang/wikis/home MSElang base types are ranges. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On 04/22/2017 03:18 AM, Martin Schreiber wrote: > On Saturday 22 April 2017 11:48:46 Graeme Geldenhuys wrote: >> On 2017-04-22 10:37, Graeme Geldenhuys wrote: >>> for the life of me I can't find that post. >> Saying that, I did track down the Delphi blog post that sparked the >> conversation on Google+ I'm looking for. >> >> https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/blog/ >> 2017-february-delphi-linux-compiler.html >> > MSElang/MSEpas does not use basic datatypes with variable size. MSEpas has > int8, int16, int32, int64, card8, card16, card32 and card64 which can be > mapped to the traditional pascal type names as you like. > > Martin Considering how many different architectures out there it is probably a wise choice to name types by size. I would. :-) Or maybe just two generic names followed by a bit size modifier like with C structures. That way you could use a 4 bit unsigned int where ever it might be convenient... not just in structures. The developer could "type" them too for type safety (type nibble = unsigned:4;). However when I started with Delphi v1 & 2 (came as a bundle) you had size specific types like "Longint" and "ShortInt" and then the generic types like "integer" were mapped to the architecture /convenient/ types: * Delphi 1 (16bit Win3x compiler) integer was 16bit signed (ShortInt). * Delphi 2 integer was a signed 32 bit int (LongInt). This was pretty much the norm for most compilers during the 16/32 bit transition. I still think its a good idea to have a type that shifts size based on architecture, for things like for loops you want to use the most machine efficient and its likely that the hardware is going to use a native size register regardless of whether you want less or not. Seems FPC lost site of this feature. I was surprised to read integer is always 32bit. I expected it to be Int64 on 64bit platforms. And as you say, one could ifdef/type a platform convenient type if they so chose. But its nice if the compiler does that for you. -- Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. j...@jfpossibilities.com 541-410-2760 Making computers work for you! -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Saturday 22 April 2017 11:48:46 Graeme Geldenhuys wrote: > On 2017-04-22 10:37, Graeme Geldenhuys wrote: > > for the life of me I can't find that post. > > Saying that, I did track down the Delphi blog post that sparked the > conversation on Google+ I'm looking for. > > https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/blog/ >2017-february-delphi-linux-compiler.html > MSElang/MSEpas does not use basic datatypes with variable size. MSEpas has int8, int16, int32, int64, card8, card16, card32 and card64 which can be mapped to the traditional pascal type names as you like. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Saturday 22 April 2017 11:37:36 Graeme Geldenhuys wrote: > On 2017-04-22 08:26, Martin Schreiber wrote: > > Again, that changes have nothing to do with LLVM > > Well all the Delphi compilers that use LLVM apparently have different > data type size too for 2-3 data types. LongWord, LongInt I think. > Coincidence with LLVM vs native compiler? Maybe not. > The ordinal types of LLVM are i1..i8388607 where the number is the bitsize. http://llvm.org/docs/LangRef.html#single-value-types So it completely belongs to the language frontend which sizes it maps to the type names. > I was pretty sure I read this information in the Delphi group on > Google+, but searching is so sh*t on Google+, for the life of me I can't > find that post. Sorry. > I tried to find information at Embarcadero about the differences of NEXTGEN - without success too. ;-) Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On 2017-04-22 10:37, Graeme Geldenhuys wrote: > for the life of me I can't find that post. Saying that, I did track down the Delphi blog post that sparked the conversation on Google+ I'm looking for. https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On 2017-04-22 08:26, Martin Schreiber wrote: > Again, that changes have nothing to do with LLVM Well all the Delphi compilers that use LLVM apparently have different data type size too for 2-3 data types. LongWord, LongInt I think. Coincidence with LLVM vs native compiler? Maybe not. I was pretty sure I read this information in the Delphi group on Google+, but searching is so sh*t on Google+, for the life of me I can't find that post. Sorry. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Friday 21 April 2017 21:20:14 Graeme Geldenhuys wrote: > On 2017-04-21 17:34, Martin Schreiber wrote: > > That is not caused by LLVM but by the changes in the language > > specification in the Delphi frontend. > > I have no clue... I'll try and find the URL of that conversation and > forward it on to you. Just in case MSELang might fall into the same trap. > In the Delphi NEXTGEN compilers they removed AnsiStrings and added ARC to classes, string indices are 0-based. There was also a talk about to remove pointers, I don't know if it really happened. Again, that changes have nothing to do with LLVM but mostly with marketing and the needs of the mobile targets and their target audience maybe. The Linux compiler is also NEXTGEN AFAIK. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Friday 21 April 2017 17:14:00 Graeme Geldenhuys wrote: > On 2017-04-21 15:52, Martin Schreiber wrote: > > The attached program on Linux-x86: > > MSElang with LLVM 3.8.0 -O3 > > So I assume the MSElang compiler will generate the same output (or very > close at least) as Delphi's new Linux compiler. Seeing as both are using > LLVM. > MSElang produces LLVM bitcode - a kind of target independed machine code in SSA form https://en.wikipedia.org/wiki/Static_single_assignment_form which will be optimized and compiled to target specific machine code by LLVM. It is also possible to execute LLVM bitcode directly in a LLVM runtime environment with just in time compilation. > It seems Embarcadero/Idera couldn't be bothered to implement their own > Linux compiler again - like they did for Kylix. So instead they simply > use LLVM. I've heard quite a lot of developers are not happy with that, > because some language behaviour and data types are now different between > Windows and Linux. So code sharing is not as good as it was with Delphi > + Kylix. > That is not caused by LLVM but by the changes in the language specification in the Delphi frontend. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
