[fpc-devel] Current state of atari port

[Thorsten Otto]

Hi,

i've pushed now the remaining parts of the AES/VDI library (and also a few 
other additions). Another few enhancements will be done soon, but the 
ObjectGEM library can already be compiled.

I just wanted to share what problems may occur when porting PurePascal code to 
FreePascal:

- the units are named differently, so for freepascal you also have to import 
the aes and vdi units, as needed. No big deal.

- Luckily, almost all the compiler switches that PurePascal uses (it only 
knows about the short directives) are named identical, and have the same 
meaning. Notable exception is the $Z switch, so have to watch out for this.

- both vdi libraries provide a vdi function that makes it possible to extend 
the interface in your application. However, in the implementation you can just 
call it with "vdi", while from an application you have to call it explicitly 
"vdi.vdi", because the unit has the same name.

- when constructing objects, ObjectGEM uses contructs like
  new(PGroupBox, init(...)
  Such constructs are not supported by FreePascal, you have to assign the 
result to some variable (i think that is also an incompatibility to 
TurboPascal)

- in a few places i got some strange warnings. For example the code
var tg,mo,jr: word;
tsetdate(((jr-1980) shl 9) or (mo shl 5) or tg);
Gives:
Hint: (4035) Mixing signed expressions and longwords gives a 64bit result

I have no idea why calculations with word (16bit) should give a 64bit result?


- ObjectGEM uses the type "integer" for all vdi/aes parameters. Since that 
might be some implementation specific size, i started to replace it in a few 
places by "smallint", and doing a "type smallint = integer;" because 
PurePascal does not know that type. That turned out to be not so a good idea: 
although the types are identical, using "smallint" in the interface part and 
"integer" in the implementation is happily accepted by FreePascal, but 
PurePascal complains about a mismatch.

- PurePascal does not seem to have a builtin unsigned 32bit integer type,so 
watch out when doing operations on longints, especially shifts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220210/c219204a/attachment.htm>