forums.silverfrost.com

[dfwlms]

My Plato IDE (Version 4.3.0) is not color-coding the EQV and NEQV logical operators, but the FTN95 compiler is apparently treating them properly. I wonder if later versions of Plato properly color-code these operators.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama

[PaulLaidler]

OK. These have been added for the next release of the 64 bit version of Plato.
The 32 bit version is frozen.

[LitusSaxonicum]

Just an observation or two on 'Frozen'.

32-bit Plato works in 32-bit and 64-bit windows, 64-bit Plato only works in 64-bit Windows. Not all computers run 64-bit Windows, not all users write applications that demand 64-bit Windows, some developers have to cater for users not running 64-bit Windows, and last, but not least, 64-bit FTN95 has more bug reports than - well you may just see what I mean.

Not that it matters to me, as I don't use Plato.

Eddie

[PaulLaidler]

Thanks Eddie.

What you write is true but I am not clear about how to respond.

[LitusSaxonicum]

Paul,

My suggestion is that you thaw it - perhaps - but the choice is ultimately yours.

I'm just pointing out some simple observations, in part conditioned by my need to 'downgrade' a travel laptop from 64-bit to 32-bit simply so that it would continue to function, as 64-bit Windows used all the available soldered-in RAM, leaving nothing with which to run programs.. 32-bit Windows freed half the RAM ...

Eddie

[PaulLaidler]

Eddie

Apart from the 64 bit debugger (which in internal and so has to be 64 bits) the differences between Plato and Plato32 are very minor. For the most part Plato32 has been fixed and stable for a number of years.

Up to now I have not had any reports from users to the effect that they are affected by this limitation. Both Plato and Plato32 are shipped in the release.

[John-Silver]

Paul wrote:

[PaulLaidler]

I refer to them as Plato and Plato32 which are the names of the executables so yes Plato means 64 bit Plato.

At the moment I expect Plato32 to remain frozen but it could be unfrozen if there is a good case to do so. It is just a case of prioritising and managing our resources.

[LitusSaxonicum]

I think that the future is entirely 64 bit. It's just that the present is both, with 32 bit having the edge for reasons mentioned. Things can, and will, change.

The colour-coding is an enhancement, not a bug fix, and that might be enough to justify not applying it to 32 bit

Eddie

[JohnCampbell]

Not sure I understand the problem.

I assume you can use 64-bit Plato to build and debug a 32-bit .exe, as well as a 64-bit .exe.
Is the problem that the 64-bit debugger is now being used for 32-bit .exe ?

Dan could be pleased that the new sdbg64 is being more generally tested.

[PaulLaidler]

The problem as I understand it that some improvements to the 64 bit Plato have not been copied to the 32 bit version.

[LitusSaxonicum]

John,

You can't use 64 bit Plato on 32 bit Windows, but you can use 32 bit Plato on 64 bit Windows. In effect, that makes 32 bit Plato more versatile - at least, until 32 bit Windows is no more, then 32 bit Plato expires with it.

Eddie

[John-Silver]

Just dropped on this post again and here's a thought - isn't it logical that all users should (at least occasionally) try out their program(s) which might have been developed on/for 32bit using 64bit Plato ... just like a few people run ftn95 on both ?

And post any problems on the forums.
Dan is always rightly encourageing the ftn95 family to make an effort to do this when possible.

This doen't necessarily mean dual-compiling through the whole development process, but from time to time, and especially at the end when a 3ébit is up and running.

This makes sense in terms of contributing to the user bug-unearthing database for Paul to iron out any glitches.
It not only helps Paul but also we users ourselves since, as eddie quite rightly points out, M$ won't be dual-supporting forever and the hardware mainstream will 'naturally' ligrate over time.
Best to be prepared in advance, and just like Covid19, public self-implication is essential in limiting shrapnel damage which might or might-not arise.

Be Prepared! I think is the motto. From both sides of the fence.

Having said that, I still personally believe it's somewhat premature to be cutting all cords with 32bit development, however eventual inevitable the ceding to the 'might' of 4bit might appear.
This opinion stems from my knowledge of very large companies being notoriously slow (understandably cautious) in changing over their 'hardware park' (upgrading 5000 machines across a company, whether it be software (Windows) or hardware related is no doddle in the park, and it's very expensive.

Covid19 and the inevitable post-pandemic commercial (cash-flow) chaos ain't gonna encourage it either.

One of the biggest (subliminaly, I typed buggest there at first !) 'dangers' is that the differences between the 2 versions is/will not be not religiously documented in one place (this is not a criticism as such, its natural evolution taking control) and can only diverge as tempus fugits ! ... .but that's an old bugbear for discussion another time and another place.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

[PaulLaidler]

Plato is an editor/IDE so in one sense it makes no difference whether it is build as a 32 bit executable or a 64 bit executable. I use Notepad occasionally but have no idea as to whether it is 32 bits or 64 bits. There is no implied bias in Plato towards using it for 32 bit or 64 bit development.

The primary purpose in moving Plato to 64 bits was to allow direct 64 bit debugging from Plato. But you can still do 32 bit debugging from the new Plato as before because that works in a different way by "talking" to the 32 bit debugger that is running in the background.

[John-Silver]

you seem to have lost the gist of your own comment Paul ....