[fpc-devel]Developer Group

[Jonas]

On Saturday, March 24, 2001, at 01:25 PM, Bartha Istvan wrote:

>  Please take a look at the 2 attachments. 
>  Read the letter first ! Thank you ! 

Please don't put your email text in an attachment the next time, this way my email client can't do the quoting for me when replying.

>Well now, I have been working with other compilers for a while, but
>  ppc386 is totally different:
>  - my programs are real fat -> a simple program ( begin  end. ) eats
>    up 56,832 KBytes, but why ?

Use -XX to compile your program, this turns on smart linking. It wll still be larger than a TP program probably, but no 50kb anymore. Use -CX to compile your own units in a smartlinkable form (this slows down the compilation process though)

>  - it takes 0.6 (min 0.5) seconds for the prog to start up, but why ?

The Dos extender has to switch to 32bit mode. Use Linux instead of Dos and this won't happen.

>  The answer is probably that the compiled programs are 32-bit progs,
 > because I had no such problem with 16-bit compilers.
 > I'm not even using the 32-bit features, and my utilities need to be small
>  and fast (and I want to use pascal), but instead they are big and slow :-(
>  What now ? Please make a 16-bit target option available.

That is really impossible. The reason is that 16bit works *completely* different from 32bit on the intel 80x86 processors: you can only use bx/si/di/bp to access memory instead of all registers for example, so the whole code generator would have to be rewritten. And the code generator is exactly one of the most complicated parts of the compiler. In addition, I thnik Dos is about the only operating system left than actually can work with 16bit code (I'm leaving out win3.xx here).

I also don't understand why you don't just use Turbo Pascal if you want a 16bit Pascal compiler: you can download it for free from Borland.

>  1. 16-bit programs are much faster in execution and characteric display
>    speed :( Borland Pascal IDE starts up and runs way beyond faster )

That's only under Dos.

>     and are much smaller ( min 3 times smaller => loads faster... ), so

The size difference isn't that big if you turn on smart linking. Ad this has little to do with the loading speed, this is because Ds is a 16 bit real mode operating system and the programs always have to switch to 32 protected mode before they can run.

>  2. As I mentioned before 32-bit programs are way too unefficient, but
>     I don't forbid you from keeping that option I just ask for a 16-bit
>     target option.

If you want to rewrite the whole code generator and implement seamless XMS/EMS memory usage, please do go ahead.

>  I can't make the graphic driver to work in any way, the machine hangs
>  for every attempt (even Ctrl-Alt-Del won't work).
>  My video card: 
 >       
 >          SVGA Chipset: RealTek RTG3106        -> a classic :-)       
 >          Display Type: Color SVGA
 >          SVGA VESA: Supported
 >          SVGA VESA version: 1.00   ( I have tried univesa too )
 
We require VESA 1.2, so you will have to use univesa in either case. What code are you using to initialize the graphics system? Have you tried using the graphdriver d8bit and graphmode m640x480?

>  - It worked fine with TurboPascal 7.0 :
>    egavga.bgi -> 320x200 and 640x480 16 color mode 
>    svga256.bgi + svga256.tpu  -> 320x200 256 color
>                                  640x400 256 color  with univesa
>                                  640x480 256 color  with univesa
 >                                 800x600 256 color  with univesa

W don't use the bgi drivers.

>  I have attached a source code to this letter, which is ripped out from
>  one of my oldest programs, but it's very character-display intensive (wow)
>  so if you don't belive me, than compile it with a 16-bit compiler and with
>  ppc386 and whatch the difference (wich one finishes faster ?).

It's logical this is slower under FPC: all writes to the text video memory have to go through the Dos memory selector, which slows it down enormously.

Really, I think for your purpose, you're better of with BP. It seems to me you are asking that we recreate BP completely (with 16bit code generation and all), which is not our goal. Our goal is BP and Delphi *compatibility*.


Jonas