[fpc-pascal] Re: interested in building a library for functions?

[Cees Binkhorst]

I downloaded the files from your website to have a look.

My first thought was 'I am looking at a program written in Reverse
Polish Notation that is literally translated into processor machinecode.'
RPN is the 'native language' of Hewlett-Packard calculators.

My second thought was that in order to be able to maintain this code you
must exactly know what it does, hence you must be a master in the art of
differential geometry & a master in processor machinecode.

The first is already a steep requirement, the second can be lethal when
you are talking about implementations on different processors ;)

Regards / Cees

On 02/26/2011 01:12 PM, Angel Montesinos wrote:
>> I think the Superficies version 2 is newer and preferred for porting.
>> The 3-D images are rotated nicely without OpenGL support. Good.
>>
>> I tried to convert it but there are 3rd party components which are not
>> ported to Lazarus.
>> Also, there are references to TBitmap.ScanLine which is not portable.
>> The Superficies v.1 seems to have much more of them, so the code has
>> become more portable.
>>
>> What are the 64-bit problems you faced?
>>
>> Regards,
>> Juha Manninen
> 
> Please, take a look to the file  OCFunctDDDoubleSafeIntegrals.pas  in
> Superficies_En. Then perhaps you may understand that it is a sort of
> minicompiler that converts strings to object code: a minicompiler that
> cannot be based on fpc. Thus, the problem of porting to 64bits (or by
> the same token to other architectures) is to change the opcodes used in
> building that object code, and also to change the relation between the
> function code and the preparation that fpc must make prior to calling
> that code, and the use that fpc will do of the results of that code.
> 
> An added difficulty that I have thumped with is that the debugger of
> fpc-Lazarus does not move, by pressing F7, from instruction to
> instruction in the CPU window, so that is difficult to catch where the
> errors arise. Another one, lesser, is that the assembler of the debugger
> CPU window is different from that used in AMD or Intel description of
> their architecture and machine instructions.
> 
> I updated yesterday Superficies so that now it may be used when the DEP
> (Data Execution Prevention) of Windows is enabled for all programs. I
> think also that by  windows emulation it may run in Linux. I am working
> now in making DEP compatible the other programs in my web page.
> 
> I know about ScanLine and components problems, and think that they are
> not difficult to bypass by using GR32 or other tricks. But this is not
> my problem at present.
> 
> I did not use OpenGl mainly because I believe that is does not provide a
> mechanism for identifying on what point of the drawn surface is the
> mouse when it moves on the surface. This is a must for many things in my
> programs.
>