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

Bartha Istvan

------------------------------
K Free E-mail http://www.k.ro/
by KappaNet http://www.kappa.ro/

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.

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.

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?

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

See Jonas's answer. I'd just make the following additional comments...

You can certainly get the exe size down substantially (to possibly as low as few k with smartlinking, depending on what you are doing)... tho' probably never as low as with TP. Also btw try upx- nothing to do with fpc- look for upx web site with search engine to get all exe sizes lower...This is useful if you don't have a very big disk. Also fpc programs always seem to take longer to load than fpc ones too.

However you'll find that many fpc programs actually run faster than tp ones if you can make use of the optimisation options. These are very good for integer (and for FP tho' this won't help you of course)... Using maximum opt. can make quite a difference- but you'll have to use 32 bit (& no assembler!) to get the advantages of this!

Other reasons for using fpc are o/s portability... plus it's new features & quick bug fixing...But maybe as Jonas said tp is still best for you...

Regards John