Replacing the C compiler will only help with Code. I do not know the source language for the 32 bit parts of the IDE, but it’s likely at least sone of it is Modula 2. So it might be necessary, butnot sufficient.
That is related to the Object File Format, not so much the C compiler. (Changing the C compiler would make it easier to debug the C code, but we dont have those sources anyway.)
To use other debuggers the Clarion Compiler would need to switch to a different OBJ format.
1 Like
The linker has supported LARGE_ADDRESS (as a setting in the EXP file) for a long time - well over a decade. If youve got NetTalk in your app its on by default. I believe theres a template setting as well. See help for LARGE_ADDRESS.
This statement is neither logical, nor accurate.
Firstly they are not “abandoning the compiler”. Thats not what was said, and clearly not intended.
Bob mentioned compiling the RTL with another compiler. From that (at most) you might infer that they wont be extending the C front-end any time soon. Indeed i doubt that part has been extended in forever. Just like the Modula 2 part hasn’t been extended in forever.
Your statement of logic is flawed because at no point does it follow that “not adding to one front end” results in “abandoning all front ends and the backend”.
Eh? I have no idea how you read that into what he said? I certainly heard nothing about making a compiler to compile Clarion to C code. That would be a fairly significant task (and frankly I’m not sure it’d give you anything. )
1 Like
This statement is neither logical, nor accurate.
Firstly they are not “abandoning the compiler”. Thats not what was said, and clearly not intended.
Bob mentioned compiling the RTL with another compiler. From that (at most) you might infer that they wont be extending the C front-end any time soon. Indeed i doubt that part has been extended in forever. Just like the Modula 2 part hasn’t been extended in forever.
Your statement of logic is flawed because at no point does it follow that “not adding to one front end” results in “abandoning all front ends and the backend”.
Eh? I have no idea how you read that into what he said? I certainly heard nothing about making a compiler to compile Clarion to C code. That would be a fairly significant task (and frankly I’m not sure it’d give you anything. )
I didnt know that so I’ll check that out because it means the 32bit apps can use 4GB of ram on 64bit windows, which can be handy.
Thanks.
In practice it’s more like 3gb. (It can -address- 4gb, but the OS uses some of that.) Also windows will “spit” programs which appear to be behaving badly (and consuming lots of Ram very quickly can look like that.)
Found the help page.
https://clarion.help/doku.php?id=module_definition_files_exp_files_.htm#the_large_address_statement
Re the spit programs which consume lots of Ram quickly, switching off Data Execution Prevention (DEP) or providing a DEP exclusion for the app will stop that.
Ive got an app here which triggers it on a vmware xp x32, but its not switched on in XP only win11 by default, so some security settings in win11 will affect vmware guest OS’es.
Okay, maybe this is due to translation difficulties. I will definitely review the conference materials again. Still, I wanted to get an answer to the question of what “SV still has to make a 64 bit compiler (because there isn’t any compiler out there that will compile Clarion source code to to the x64 instruction set.)” means. So, do you think it will be a 64-bit version of the Topspeed Clarion compiler or a completely new development?
In the below post I wonder if Z @RZaunere is saying what you’re saying? It comes down to exactly what “Lives On” means. I for one can “Live” with a different OBJ format. I just need to rebuild.
What’s the point of telling us the above and below if the Clarion code cannot use all the tools?
What only makes sense to me is the entire Build Process switches to the OBJ and DBG formats used by everyone else. Then SV can use common open source Debug and other Build / Analysis Tools, and so can we if Clarion has the same OBJ/DBG file format.
What sense would it make for the C compiler to produce a different OBJ and DBG format than the Clarion compiler? Then the Linker has to deal with both OBJ formats?
He says the Modula compiler is going into Semi Retirement. IIRC the Debugger is written in TopSpeed Modula 2.
2 Likes
I have no data to make an assumption one way or the other. Any thoughts would just be rampant speculation which would about as valuable as what color box i think it will ship in.
The linker does not link OBJs for the RTL with OBJs from your Clarion code.
The RTL libraries are compiled and linked into DLLs and LIBs in Florida. They do not ship the OBJs.
Your Clarion code is compiled and linked in Chicago. You dont ship your OBJs to Florida. So theres no need, and indeed no opportunity, for any linker to see both OBJs at the same time.
Ok. This is a key question for understanding what the words RZ really mean. Without an answer to it, other arguments don’t make sense.
If you say so. I don’t see the confusion myself, but hey - you do you.
I think he’s referring to when we compile C code into our Clarion application, not what they use to create the RTL.
I apologize in advance, but I have a simple question.
There are people on the forum who know that R.Zauner really running the SV project now?
Not by email or message, but as a real person ?
Thank you in advance for your honest answer.
I’m really not sure I understand what you are asking.
But yes, Bob Zaunere is a real person. He has attended all the CIDC event since 2011, and Devcons before that going back to at least 1998 when i first met him.
So where’s my C12 link? 
I’m anxious to see the new looks if nothing else 
I don’t doubt it. I even saw his picture.
But is he currently involved in SV projects?
Robert used infographics in all Devcon reports.
The one who wrote the message dated 05.12.2024 does not know how to do this …