Free Pascal target Atari

[mfro]

Having the VDI "uses" AES feels plain wrong, when in reality it's exactly the opposite.

[ChainQ]

because MFORM clearly looks like to be an AES type

Not really. All that AES does internally, is to pass the pointer to vsc_form(). In C-headers (like for Pure-C, where you also have different include files for AES and VDI), there is a similar problem that you have to take care not to redefine the type.

There's an important difference - C has a single namespace for everything, including its includes, that's not true for Pascal. Which is part of the problem that you tried to work around here, I understand. But it's simply not needed, if you have a single type.

and made VDI to just have uses aes,

That works for compiling the library, but not for applications. If you do something like

Code: Select all

uses aes, vdi;

var m: TMFORM;
..
vsc_form(vdiHandle,@m);

You get an error, because "m" actually has the type aes.TMFORM, and you are passing that to vdi.

No, it does work, because Pascal doesn't re-export symbols and types from the used units in the interface section. So there is simply no vdi.TMFORM type any more, only the aes.TMFORM (a.k.a. simply TMFORM), and that is used across the code and works everywhere, including the interface definition of that VDI call.

Also "uses aes" in vdi (or vice versa) seems not very clean to me, and i wanted to avoid that. There might actually be examples that use only one or the other library (higem uses only aes for example). But thats all only very philosophical

I agree that it's not that pretty, but IMO it's more Pascal-ish than trying to define a global type somewhere in a separate unit, and just define alias types all over the place. Also, as we're talking about a solution which doesn't add any code to the final binary, it's indeed only philosophical.

There may be other (upcoming) double definitions of that kind. The PRN_SETTINGS structure (used by the pdlg_* functions) is mainly an AES type. But there is also a VDI function v_read_default_settings that needs it.

Which honestly to me just reinforces the idea to sadly we should make that "uses aes" sacrifice in VDI.

[ChainQ]

Having the VDI "uses" AES feels plain wrong, when in reality it's exactly the opposite.

We can actually have it the other way around - have the type defined in VDI, and make uses vdi; in AES, if that flies better with some people? But I'm not sure what's the consequences of that for upcoming stuff.

My point is, now looking deeper into this, I don't like the idea that types shared across the system are declared in a separate unit, and then aliased by everyone. There's really no reason to do that apart from the philosophical discussion in the previous post.

[ThorstenOtto]

Maybe i misunderstood that, but if you define the type just in VDI, than have the aes unit "uses VDI", the type won't be visible to applications that just use aes? For that you have to define an alias anyway?

But i'm fine with any solution, as long as applications gets the types they need.

[ChainQ]

Maybe i misunderstood that, but if you define the type just in VDI, than have the aes unit "uses VDI", the type won't be visible to applications that just use aes?

No, it won't. But I guessed because it doesn't add extra code to the application, pulling in dependencies this way isn't a problem. If you need that call and that type, you add "vdi" to the uses line, done.

For that you have to define an alias anyway?

Normally you don't, except the way it's currently done: you insist that a type shared by multiple subsystems be defined in multiple units, so you have to cross-reference it via a 3rd unit, so the compiler doesn't complain that they're distinct types. I don't see a lot of meaning in this, because I'm quite sure most complex applications will need both AES and VDI, so the entire discussion is theoretical really.

But i'm fine with any solution, as long as applications gets the types they need.

Since we're basically making a new API, does it really matter what needs to be in the uses line for types to work?

But to draw a line below the above discussion: since there's no agreement in how this should be done, and I'm certainly not an experienced Atari developer to decide, I'll just go back to the original idea to rename the gemcommon unit, so at least it's 8.3. At least I think we got an answer that why Pure Pascal just had a global "GEM" unit instead of trying to split these up into separate unit.

Edit: the rename change is committed and pushed now.

[mfro]

A completely different question: is there any standard/convention on how FreePascal for different targets would be installed side by side?

I would like to be able to compile both for ColdFire and "standard" m68k and - if there happens to be a convention - rather follow that than nail together something myself.

[ChainQ]

A completely different question: is there any standard/convention on how FreePascal for different targets would be installed side by side?
I would like to be able to compile both for ColdFire and "standard" m68k and - if there happens to be a convention - rather follow that than nail together something myself.

There's no standard naming for one platform with multiple sets of units, at least for Atari right now. In theory we could include something we call "CPU subarchitecture" (000 vs. 020 vs. cf for example), but because the various compiled sets of units can differ in various ways (on Amiga for example we have Kickstart 1.2 and 3.1 builds, even for the same CPU), just adding the subarch is not always a meaningful solution, and you can have additional non-standard sets. Anyway, since the compiler and tools are identical as long as you target the same CPU architecture, you basically just need the different sets of units somewhere. If we're talking about a cross-compiler, you can ignore 8.3 limits, so the units could go to lib/fpc/$fpcversion/units/atari-000 (just rename the dir, and adjust the lines in your config file) and lib/fpc/$fpcversion/units/atari-cf respectively. Then you just need a matching config file and a -Cp parameter on the command line to select the right CPU arch, and with that the right -Fu parameters and units from the config file.

This convention is also used when you have units for multiple completely distinct systems and even compilers for different CPU archs next to each other. This is why you have an extra directory level inside the units directory with the name of the platform.

What I do in practice for cross-compiling: I don't do "zipinstall" but "install", then I specify an INSTALL_PREFIX= parameter to the make line, which is something like $HOME/somedir/fpc-bin/m68k-atari-000 for plain 68000, $HOME/somedir/fpc-bin/m68k-atari-cfv4e for Coldfire, or any other combination of OS-platform I need, and I have a lot. This has the advantage that the compiler remains bundled with the units, which is good, because in the development version, the unit format changes relatively often, and then I don't have to update all the units at the same time, or I can keep a certain build "fixed" while working on the others, etc. But it has the disadvantage, that I don't have a "central" compiler binary, and always have to specify all paths when I'm compiling something. Due to the nature of my use case (compiler development), this has proven to be better for me. I'm not recommending it, but it might work for you, if you run into some limitations with the first approach.

This is the contents of my current "fpc-bin" directory, btw:

Many FPCs

In each of these directories, there's the usual directory structure with compiler, units, etc.

On a related note, I should _REALLY_ update the FPC wiki page entry on Atari, because there were a lot of changes recently, and then I could maybe include a few words about this too, which is tuned to end users.

Ok, this post ended up being a bit all over the place, but hope you can still figure something useful out from it.

[mfro]

Installed into units/atari-00 and units/atari-cf directories, respectivly. Works fine, thank you.

It appears the metados unit is missing from the install target and only gets copied by chance (the very first time).
This should fix it:

Code: Select all

diff --git a/packages/tosunits/fpmake.pp b/packages/tosunits/fpmake.pp
index 2f2d9623c6..3971176599 100644
--- a/packages/tosunits/fpmake.pp
+++ b/packages/tosunits/fpmake.pp
@@ -37,6 +37,7 @@
     T:=P.Targets.AddUnit('gem.pas');
     T:=P.Targets.AddUnit('gemcmmn.pas');
     T:=P.Targets.AddUnit('nf_ops.pas');
+    T:=P.Targets.AddUnit('metados.pas');
 
     P.ExamplePath.Add('examples');
     T:=P.Targets.AddExampleProgram('higem.pas');

[ChainQ]

It appears the metados unit is missing from the install target and only gets copied by chance (the very first time).

Thanks, fix committed. It's compiled anyway, because several units which use it will pull it in, but yeah, the rebuild or copy process might be incomplete in this case. I always clean before rebuild, so I didn't notice it.

[ThorstenOtto]

I'm all for a better example, of course. I don't even pretend I knew what I was doing, so feel free to fix it and thank you.

Done now with recent PR.

There are also a few bug fixes in it for the new bindings for stupid mistakes all (c) by me If someone got the time and patience, it might be good if he could look over the code, there might be some other bugs of such kind hiding.

Beside from that, there are now mainly the wdialog functions missing. Question is: should they also be implemented? PurePascal does not have them in the gem unit, so any application that needs them (like Texel), will have to implement them on its own. And if we do, should there be

• separate units, like i did in my fork of texel
• a single wdialog unit
• or just add them to the AES unit.

As for Texel, it currently can be compiled and starts up, but there seems to be some things i've missed, or differences i'm not aware of. Only a few of the example sheets can be loaded so far, most of the time i get either an error during loading, a runtime error, or just a crash.

[mfro]

Just got FreePascal Texel running on the FireBee (ColdFire native).

There are lots of rough edges (like redraw errors, graphics artifacts, some of the example sheets not loading or even hard crashes ), but basically it's working.

Good job so far (thank you), but still a way to go.

texel.png

[couldn't resist proudly showcasing on our FireBee native fVDI ]

[ChainQ]

Done now with recent PR.

I submitted a review of the PR, there are a few suggestions, and basically a requested change, regarding fpGetEnv().

There are also a few bug fixes in it for the new bindings for stupid mistakes all (c) by me If someone got the time and patience, it might be good if he could look over the code, there might be some other bugs of such kind hiding.

Yeah, sadly these initial wrinkles also took quite some time in the Amiga port to get ironed out. There's really two ways, either you start writing a lot of test code, or you keep fixing issues as they surface. We were too lazy to write a lot of tests, and also sometimes it won't even help on Amiga-likes due to the lack of memory protection. Simple things tend to work, but then larger stuff or subsequent calls crash. This makes writing reliable test code a bit tricky. But fortunately we also started using a bigger and bigger API surface with our programs which we wrote in FPC, so things got fixed in the end... Fortunately this is open source, so anyone who's willing to check what's going on, can. I don't see a way around this really, but very open to input.

Beside from that, there are now mainly the wdialog functions missing. Question is: should they also be implemented? PurePascal does not have them in the gem unit, so any application that needs them (like Texel), will have to implement them on its own. And if we do, should there be

• separate units, like i did in my fork of texel
• a single wdialog unit
• or just add them to the AES unit.

Small utility and wrapper functions which are directly related to OS interface, I'd put it directly into the OS interface unit itself, for more complex stuff, which builds on an OS interface rather than extending it, I'd do a separate utility unit. We more-or-less used the same principle in the Amiga port as well, and worked out OK.

[ChainQ]

Just got FreePascal Texel running on the FireBee (ColdFire native). There are lots of rough edges (like redraw errors, graphics artifacts, some of the example sheets not loading or even hard crashes ), but basically it's working.

Given how untested the FPC CF support lately is, I'm positively surprised it works to this level. So congrats! A somewhat related question: is there a ColdFire Linux distro in binary, which one can just download and start using? Ideally compiled for CFv4e. I'd like to setup a QEMU-based test environment, but for that one needs a bit of Linux userland.

I mean, I could build a simple one for ourself using Buildroot, which I have quite some knowledge in, but I'd avoid spending time on it if not totally necessary.

[ThorstenOtto]

I think you don't need a ColdFire linux for this purpose. QEMU for 68k currently only emulates the userspace code, not the kernel.

[ChainQ]

I think you don't need a ColdFire linux for this purpose. QEMU for 68k currently only emulates the userspace code, not the kernel.

Sure, I don't want to emulate the entire machine, but as I wrote, I still need a bit of userland. Mainly a shell, a couple of C libraries (testing linking against C functions is a thing), and so on. I just guessed this was easier to extract from an already existing binary distro, if it exists.

[mfro]

... A somewhat related question: is there a ColdFire Linux distro in binary, which one can just download and start using? Ideally compiled for CFv4e...

The closest thing I've ever seen was a uClinux kernel image that booted in a very early qemu-m68k years (if not even tenths of years) ago.

Did a quick search for it, but unfortunately it seems all the uClinux stuff is all long gone.

[mfro]

...
As for Texel, it currently can be compiled and starts up, but there seems to be some things i've missed, or differences i'm not aware of. Only a few of the example sheets can be loaded so far, most of the time i get either an error during loading, a runtime error, or just a crash.

Just noticed: while most of the example spreadsheets don't want to load cleanly or even crash (in both my ColdFire version as well as the '000 version I use on Hatari) - I can cleanly (re)load all of the files I've newly saved with the FreePascal version.

I'm suspecting there is either some alignment issue or maybe a type size mismatch.

[ChainQ]

Just noticed: while most of the example spreadsheets don't want to load cleanly or even crash (in both my ColdFire version as well as the '000 version I use on Hatari) - I can cleanly (re)load all of the files I've newly saved with the FreePascal version.

I'm suspecting there is either some alignment issue or maybe a type size mismatch.

Try to do a clean recompile of Texel & ObjectGEM with the compiler argument -CPPACKRECORD=2, and see if that changes this behavior.

[ThorstenOtto]

I'm suspecting there is either some alignment issue or maybe a type size mismatch.

Looks like they are "encrypted" (but without using a password). You can check that in the File/Info dialog. For decryption, a seed stored in the file, and system.random is used. If that function does not produce the same results as the one from PurePascal, you'll get garbage.

So i guess we have to replace the call to system.random with the code from PurePascal's random function.

You could try loading the files with the orginal Texel, remove that encryption, and save them again. After that, loading the file in the FreePascal version works, at least for some of them.

[mfro]

I'm suspecting there is either some alignment issue or maybe a type size mismatch.

Looks like they are "encrypted" (but without using a password).
...
If that function does not produce the same results as the one from PurePascal, you'll get garbage.

Ah, makes sense.

Btw. why did you replace the VAR with OUT in the read... functions? Shouldn't VAR work just as well (or ist that an attempt to speed up loading)?

[ThorstenOtto]

Just to get rid of the warnings that FPC otherwise generates.

[ThorstenOtto]

Oh well, next problem is something i should have known: different size/format of the "real" type. PP uses a 10-byte format (same as internal FPU extended, but without the filler word). But FPC does not seem to support the extended type for m68k, and on ColdFire this isn't available anyway.

So for now, the only solution seems to be to convert the format while reading/writing at least. Of course that could mean some loss of precision, or even overflow/underflow if values outside the range of a double are stored in files.

For m68k, that could be avoided if FPC would support the extended type (is that easily doable?). But on ColdFire, there is no choice about that.

[ChainQ]

This is a long standing question, and yes, FPC doesn't support the 80 bit extended type on anything but x87, and I intentionally made the decision to not support it for m68k for the time being, because the future regarding extended type support was in flux. There is a software float library being discussed, which will allow support for "modern" floating point types like half precision, or 80 bit, or even 128bit floating point to be calculated regardless of the target FPU capabilities. However, this will also be slower then in many cases. And even if we have this, m68k still needs special support, because of the lack of the padding word in the "used-in-the-field" extended format. So I'd really like to avoid hacking this into the m68k code generator for now...

Extended FPU support is also something quite difficult to test, because most emulators do a lot of floating point shortcuts for performance reasons, and doesn't exactly mimic the physical 68k FPU results in many ways, so this will all result in failing tests, even if the code generated is correct in principle. We already have a plenty of failed test even with 64bit precision because of this, sadly.

BTW, FPC also doesn't support Turbo Pascal's 48bit "real" type for the same reason. So you'll need to convert these it by hand indeed, for now, in applications that need it. Not sure if Pure Pascal supports that format. However, to be honest, I also haven't looked into this for a while, I think I'll also look into what we have right now to support 80bit extended in software, maybe that could also help on the ColdFire.

Edit: Looks like the SoftFPU has some helpers for floatx80_to_float64 and vice-versa. I think for the 80bit functions to be available, you have to include the unit "sfpux80" unit in the uses line. unit "ufloatx80" also provides basic operator overloading for easy handling of the floatx80 type. These are already being built for Atari as far as I can see.

Edit 2: Note I have no experience personally with using these functions, but feel free to try.

[ThorstenOtto]

And even if we have this, m68k still needs special support, because of the lack of the padding word in the "used-in-the-field" extended format.

But for x87 its the same, the external format is also 96 bit, just in little-endian order?

But i looked at the code that PP produces when compiled for 68881, and using the real type. It really has hard times to store those values. The code to store FP0 at (a0) is

Code: Select all

             FMOVE.X     FP0,-(A7)
             MOVE.W      (A7)+,(A7)
             MOVEA.L     A0,A1
             MOVE.L      (A7)+,(A1)+
             MOVE.L      (A7)+,(A1)+
             MOVE.W      (A7)+,(A1)+

Not sure if Pure Pascal supports that format.

No, it doesn't. Only 4,8,10, and 12-bytes formats.

However, to be honest, I also haven't looked into this for a while, I think I'll also look into what we have right now to support 80bit extended in software, maybe that could also help on the ColdFire.

That would atleast help in not loosing precision. I'm not sure whether an FPU version is really needed (although Texel would clearly be one the applications which benefits the most of this), but AFAIK, even the official versions were compiled with softfloat. Maybe in the end its not that noticable, and all the bookkeeping really takes more time than the actual calculations.

[ChainQ]

And even if we have this, m68k still needs special support, because of the lack of the padding word in the "used-in-the-field" extended format.

But for x87 its the same, the external format is also 96 bit, just in little-endian order?

No. The x87 extended format is 80 bit also in memory, so 10 bytes long, not 12, and of course little endian. And yes, I want to avoid doing that kind of 80bit float store mess which you posted.

However, to be honest, I also haven't looked into this for a while, I think I'll also look into what we have right now to support 80bit extended in software, maybe that could also help on the ColdFire.

That would atleast help in not loosing precision. I'm not sure whether an FPU version is really needed (although Texel would clearly be one the applications which benefits the most of this), but AFAIK, even the official versions were compiled with softfloat. Maybe in the end its not that noticable, and all the bookkeeping really takes more time than the actual calculations.

Yeah, see the bottom of my previous post which I edited, that should solve this, if you include both floatx80 and ufloatx80 units, plus you need to redefine the type Extended to Floatx80 I think, in all units that has any sort of extended math. In theory. But I can't test now. So please do and report back, if you think so. But at least this would also then work for ColdFire, if it does work, and also it won't matter if the rest of the binary is compiled for hardware or software floating point.