FPC - Oh joy...
Robert AH Prins
So I finally decided to install FPC (2.2.2), pulled from the FreePascal
site.
Full install in D:\FPF\2.2.2
Start a command prompt in the bin\i386-win32 directory, using my default
window of 140x63 with size 15 font and wow, I get a nice big screen,
but... the logo looks distinctly fishy starting with 'GeC' on the last
visible line followed by some more graphical stuff. The 'F' of FPC is
cut off. (XP SP3, Athlon64 3700+, 1Gb, pretty standard PC)
OK, logo is not overly interesting, let's load a file.
Hm, ..\ entries are at the bottom of a not-resizable file selection box,
could (NO, should!) be better...
navigate to required file, load it, hit F9 and are greeted by an
"Error: Illegal parameter: -Opentium3"
message. Hm, where did *I* enter this? Options, Compiler? There it is as
an Additional compiler argument. OK, blank it out, hit F9 again.
This time I get:
Fatal: Unable to open file D:\FPC\2.2.2\bin\i386-win32\fp.cfg
Fatal: Compilation aborted
but fp.cfg *IS* in this directory and despite blanking out '-Opentium3'
it's still in there...
I haven't even tried fpc, as it calls my Athlon 64 an i386...
What am I doing wrong? TP2 worked right out of the box, so did TP3.01a,
TP6, BP7.01, VP 2.1.279, so I do have a bit of experience with Pascal.
Somewhat disappointed, to be very polite after wasting about two
hours...
Robert
--
Robert AH Prins
robert dot ah dot prins on gmail
Marco van de Voort
> So I finally decided to install FPC (2.2.2), pulled from the FreePascal
> site.
>
> Full install in D:\FPF\2.2.2
>
> Start a command prompt in the bin\i386-win32 directory, using my default
> window of 140x63 with size 15 font and wow, I get a nice big screen,
> but... the logo looks distinctly fishy starting with 'GeC' on the last
> visible line followed by some more graphical stuff. The 'F' of FPC is
> cut off. (XP SP3, Athlon64 3700+, 1Gb, pretty standard PC)
It's the logo as it is. Don't see any errors if I try to duplicate that.
People's taste can differ of course.
> OK, logo is not overly interesting, let's load a file.
>
> navigate to required file, load it, hit F9 and are greeted by an
>
> "Error: Illegal parameter: -Opentium3"
> message. Hm, where did *I* enter this? Options, Compiler? There it is as
> an Additional compiler argument. OK, blank it out, hit F9 again.
Known problem of 2.2.2. The setup procedure incorrectly preconfigured this.
Should have been "-Oppentium3". Is fixed in trunk.
> This time I get:
>
> Fatal: Unable to open file D:\FPC\2.2.2\bin\i386-win32\fp.cfg
> Fatal: Compilation aborted
>
> but fp.cfg *IS* in this directory and despite blanking out '-Opentium3'
> it's still in there...
>
> I haven't even tried fpc, as it calls my Athlon 64 an i386...
It falls back to that because of the preconfiguring for P-III failed (which
is generally a good choice unless you have a P IV afaik) IOW it is the same
problem.
> What am I doing wrong? TP2 worked right out of the box, so did TP3.01a,
> TP6, BP7.01, VP 2.1.279, so I do have a bit of experience with Pascal.
Minor problem in the installer, not the ide/compiler. Was not enough
enthusiasm for repacking, can be fixed by inserting a "p". Don't let it
discourage you.
prino
> On 2008-10-20, Robert AH Prins <spamt...@prino.org> wrote:
>
> > So I finally decided to install FPC (2.2.2), pulled from the FreePascal
> > site.
>
> > Full install in D:\FPF\2.2.2
>
> > Start a command prompt in the bin\i386-win32 directory, using my default
> > window of 140x63 with size 15 font and wow, I get a nice big screen,
> > but... the logo looks distinctly fishy starting with 'GeC' on the last
> > visible line followed by some more graphical stuff. The 'F' of FPC is
> > cut off. (XP SP3, Athlon64 3700+, 1Gb, pretty standard PC)
>
> It's the logo as it is. Don't see any errors if I try to duplicate that.
> People's taste can differ of course.
Aside from the esthetics, can you send me a screen-print of the logo,
I just have the feeling that what I see is not correct.
> > OK, logo is not overly interesting, let's load a file.
>
> > navigate to required file, load it, hit F9 and are greeted by an
>
> > "Error: Illegal parameter: -Opentium3"
> > message. Hm, where did *I* enter this? Options, Compiler? There it is as
> > an Additional compiler argument. OK, blank it out, hit F9 again.
>
> Known problem of 2.2.2. The setup procedure incorrectly preconfigured this.
> Should have been "-Oppentium3". Is fixed in trunk.
OK, but if I change this in the Compiler/Options tab, why does it not
change in fp.cfg??
> > This time I get:
>
> > Fatal: Unable to open file D:\FPC\2.2.2\bin\i386-win32\fp.cfg
> > Fatal: Compilation aborted
>
> > but fp.cfg *IS* in this directory and despite blanking out '-Opentium3'
> > it's still in there...
>
> > I haven't even tried fpc, as it calls my Athlon 64 an i386...
>
> It falls back to that because of the preconfiguring for P-III failed (which
> is generally a good choice unless you have a P IV afaik) IOW it is the same
> problem.
So what pre-configures this to P-III, there's nothing during the
installation to indicate that it's detecting a P-III and a CPUID
anywhere in the routine to do this pre-configuration should make it
obvious that it's running on an AMD...
> > What am I doing wrong? TP2 worked right out of the box, so did TP3.01a,
> > TP6, BP7.01, VP 2.1.279, so I do have a bit of experience with Pascal.
>
> Minor problem in the installer, not the ide/compiler. Was not enough
> enthusiasm for repacking, can be fixed by inserting a "p". Don't let it
> discourage you.
I've just converted a bunch of old 16-bit programs to VP, but not
entirely unexpected, the generated code is almost as, how to express
this politely, 'not very good' as the old TP code - I did have two
versions of the TP code, plain TP and TP mixed with very heavy doses
of built-in 16-bit assembler, I obviously moved the pure Pascal
version to VP. Both TP and VP generate really great (NOT!) code for
things like
case mode of
' ': if (wait^[_j]^.time < wait^[_k]^.time) or
(wait^[_j]^.time = wait^[_k]^.time) and
(wait^[_j]^.type < wait^[_k]^.type) then
inc(_j);
'T': if (wait^[_j]^.type < wait^[_k]^.type) or
(wait^[_j]^.type = wait^[_k]^.type) and
(wait^[_j]^.time < wait^[_k]^.time) then
inc(_j);
'C': if (wait^[_j]^.cnty < wait^[_k]^.cnty) or
(wait^[_j]^.cnty = wait^[_k]^.cnty) and
(wait^[_j]^.time < wait^[_k]^.time) then
inc(_j);
'Y': if (wait^[_j]^.year < wait^[_k]^.year) or
(wait^[_j]^.year = wait^[_k]^.year) and
(wait^[_j]^.time < wait^[_k]^.time) then
inc(_j);
end;
part of a heapsort on two fields. I was trying to get an idea of the
code that FPC generates for this, it's unlikely to get anywhere near
what I originally coded in BASM, but I would expect it to do
(substantially) better than both TP and VP...
Robert
--
Robert AH Prins
robert.ah.prins at the big one on Google
Marco van de Voort
>> > but... the logo looks distinctly fishy starting with 'GeC' on the last
>> > visible line followed by some more graphical stuff. The 'F' of FPC is
>> > cut off. (XP SP3, Athlon64 3700+, 1Gb, pretty standard PC)
>>
>> It's the logo as it is. Don't see any errors if I try to duplicate that.
>> People's taste can differ of course.
>
> Aside from the esthetics, can you send me a screen-print of the logo,
> I just have the feeling that what I see is not correct.
http://www.stack.nl/~marcov/fpcidelogo.png
In the wider mode it looked the same, it doesn't stretch.
It could be of course that you configured a different codepage for that
dosbox. The textmode IDE is still Turbo Pascal string based, so uniocde is
out of the option for now.
>> Known problem of 2.2.2. The setup procedure incorrectly preconfigured this.
>> Should have been "-Oppentium3". Is fixed in trunk.
>
> OK, but if I change this in the Compiler/Options tab, why does it not
> change in fp.cfg??
Well, from what I guessed, the files in the same dir as the .exe function as
a kind of template for a local configuration. IOW your chances were saved
locally.
The fp.ini and fp.cfg files are human editable btw, fp.dsk is not. (turbo
vision streams afaik)
>> It falls back to that because of the preconfiguring for P-III failed (which
>> is generally a good choice unless you have a P IV afaik) IOW it is the same
>> problem.
>
> So what pre-configures this to P-III, there's nothing during the
> installation to indicate that it's detecting a P-III and a CPUID
> anywhere in the routine to do this pre-configuration should make it
> obvious that it's running on an AMD...
P-II/III is the general safe default. It causes only problems on really,
really old computers, and except maybe for P IV that default is already
pretty close to the optimum. Keep in mind that Athlon was built to compete
with P-III originally and that Core-* series are descendants of P-III (via
P-M). Leaving P-IV as the ugly duckling.
Or at least that is what I understood. Jonas is most knowledgable about
optimization stuff, and he occasionally also wanders into c.l.p.m.
>> Minor problem in the installer, not the ide/compiler. Was not enough
>> enthusiasm for repacking, can be fixed by inserting a "p". Don't let it
>> discourage you.
>
> I've just converted a bunch of old 16-bit programs to VP, but not
> entirely unexpected, the generated code is almost as, how to express
> this politely, 'not very good' as the old TP code - I did have two
> versions of the TP code, plain TP and TP mixed with very heavy doses
> of built-in 16-bit assembler, I obviously moved the pure Pascal
> version to VP. Both TP and VP generate really great (NOT!) code for
> things like
I've no idea how this particular construct fares. How does this code fare in
Delphi, FPC should be about the same or slightly better even, from time to
time.
If you have problems, make a small compilable example of the construct,
which is preferably correct in the scope of the variables (local,
global,parameter). I'll then try to rearrange it a bit to see if the
compiler fares better. It is possible the case statement blocks the
optimizer from getting stuff into registers.
> part of a heapsort on two fields. I was trying to get an idea of the
> code that FPC generates for this, it's unlikely to get anywhere near
> what I originally coded in BASM, but I would expect it to do
> (substantially) better than both TP and VP...
Probably everything rides on how many values (and/or subexpressions) can be
stuffed in registers.
Compilers can't always see manual tricks.
Jonas Maebe
Marco van de Voort <mar...@stack.nl> wrote:
> P-II/III is the general safe default. It causes only problems on really,
> really old computers,
No, it does not cause problems anywhere. -Op<x> simply means "generate
optimal code for processor <x>", not "generate code requiring at least
processor <x>".
And the fact that the -Opentium3 error slipped into the 2.2.2 release is
because apparently nobody (including the person who made that change)
tested the IDE before that release. Which is indeed very bad.
> > I've just converted a bunch of old 16-bit programs to VP, but not
> > entirely unexpected, the generated code is almost as, how to express
> > this politely, 'not very good' as the old TP code - I did have two
> > versions of the TP code, plain TP and TP mixed with very heavy doses
> > of built-in 16-bit assembler, I obviously moved the pure Pascal
> > version to VP. Both TP and VP generate really great (NOT!) code for
> > things like
>
> I've no idea how this particular construct fares. How does this code fare in
> Delphi, FPC should be about the same or slightly better even, from time to
> time.
FPC's common subexpression elimination at the assembler level will get
some of the redundancy, but far from all of it. Better results will be
achieved once the llvm backend is ready and/or CSE at the tree node
level works (both are works in progress).
Jonas
Marco van de Voort
>> P-II/III is the general safe default. It causes only problems on really,
>> really old computers,
>
> No, it does not cause problems anywhere. -Op<x> simply means "generate
> optimal code for processor <x>", not "generate code requiring at least
> processor <x>".
Correct. Meant to set "if only" or so.
> And the fact that the -Opentium3 error slipped into the 2.2.2 release is
> because apparently nobody (including the person who made that change)
> tested the IDE before that release. Which is indeed very bad.
Yup, and IMHO repackage (win32/64 only? go32v2 too?) was warranted. The
textmode IDE is not the brightest, shiniest part, but the potential
confusion too large.
>> > of built-in 16-bit assembler, I obviously moved the pure Pascal
>> > version to VP. Both TP and VP generate really great (NOT!) code for
>> > things like
>>
>> I've no idea how this particular construct fares. How does this code fare in
>> Delphi, FPC should be about the same or slightly better even, from time to
>> time.
>
> FPC's common subexpression elimination at the assembler level will get
> some of the redundancy, but far from all of it.
I was careful because I didn't know if the CSE'd expression would/could be
hoisted out of the case block properly. Specially when the case block was
large and each node different. Or if it even could be useful since it looks
like the index vars can change any iteration.
aaa
> Hi all,
>
> So I finally decided to install FPC (2.2.2), pulled from the FreePascal
> site.
>
> Full install in D:\FPF\2.2.2
There are people who write -Opentium3 instead of -Oppentium3 and others
who write D:\FPF instead of D:\FPC. It is easy to make typing errors,
isn'it? :-)
> Start a command prompt in the bin\i386-win32 directory, using my default
> window of 140x63 with size 15 font and wow, I get a nice big screen,
> but... the logo looks distinctly fishy starting with 'GeC' on the last
> visible line followed by some more graphical stuff. The 'F' of FPC is
> cut off. (XP SP3, Athlon64 3700+, 1Gb, pretty standard PC)
>
> OK, logo is not overly interesting, let's load a file.
>
> Hm, ..\ entries are at the bottom of a not-resizable file selection box,
> could (NO, should!) be better...
>
> navigate to required file, load it, hit F9 and are greeted by an
>
> "Error: Illegal parameter: -Opentium3"
>
> message. Hm, where did *I* enter this? Options, Compiler? There it is as
> an Additional compiler argument. OK, blank it out, hit F9 again.
>
> This time I get:
>
> Fatal: Unable to open file D:\FPC\2.2.2\bin\i386-win32\fp.cfg
> Fatal: Compilation aborted
>
> but fp.cfg *IS* in this directory and despite blanking out '-Opentium3'
> it's still in there...
>
> I haven't even tried fpc, as it calls my Athlon 64 an i386...
>
> What am I doing wrong? TP2 worked right out of the box, so did TP3.01a,
> TP6, BP7.01, VP 2.1.279, so I do have a bit of experience with Pascal.
>
> Somewhat disappointed, to be very polite after wasting about two
> hours...
How many hours did the FPC developpers spend on their free compiler?
FPC works. And it works on about all OS. Moreover, considering that now
Delphi is dying, FPC is the only future of Pascal (assuming Pascal can
still have a future). What else? The obsolete compilers you quoted?
mm
----
http://www.ellipsa.net/
CBFalconer
> Robert AH Prins a écrit :
>
>
>> What am I doing wrong? TP2 worked right out of the box, so did
>> TP3.01a, TP6, BP7.01, VP 2.1.279, so I do have a bit of
>> experience with Pascal.
>>
>> Somewhat disappointed, to be very polite after wasting about two
>> hours...
>
> How many hours did the FPC developpers spend on their free
> compiler?
>
> FPC works. And it works on about all OS. Moreover, considering
> that now Delphi is dying, FPC is the only future of Pascal
> (assuming Pascal can still have a future). What else? The
> obsolete compilers you quoted?
Bear in mind that, of the the systems named by Prins, none
implement Pascal. (I am not familiar with VP 2.1.279). In
particular, they don't implement f^, or the put, or get
procedures/functions, and have significant mistakes in the
implementation of other standard system functions. It is alright
to add extensions, it is not alright to ignore standard
requirements.
Some of these can be corrected with my txtfiles.zip package. See:
<http://cbfalconer.home.att.net/download/txtfiles.zip>
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
GMorris
ridiculous in
this day and time anyway!), however I've been reading it and the very first
post in this thread
mimics almost EXACTLY the way FPC did on my laptop. I have a Linux machine,
very old,
and it runs FPC just fine "out of the box", so to speak. I figured out
the -Opentium3 deal,
but never saw anything else about the fp.cfg file being tied up. After I got
that message, I
went and looked for the file, found it, and tried to open it. With the text
IDE open, it was
declared to be "in use" by Windows, and when the IDE was closed the file was
released. I
can not compile ANYTHING through the IDE because of this and was hoping that
some
kind person would address that part of the post.
The only problem I get on Linux is, when opening the text IDE (both machines
run 2.2.2, by
the way) it really screws with the key bindings for ALL consoles, and turns
the ESC key
into another way to compile while in the IDE. That is, unless I use X and
start it from an X
console window. Then it doesn't bother any of the keys, but that's minor
compared to the
Windows problem. Anyone have a clue why the fg.cfg file is being held
hostage by the IDE?
In Vista, I open a console within Windows, then change to my working dir and
type the
standard 'FP' to start the IDE. It's obviously in need of some work, but
this is just crazy.
It's really not much more than a glorified Pascal editor when you cannot
compile through it.
I even looked at file permissions, and after a while I went so far as to
just move the whole
dir structure and try running it from another place, but that did squat as
well. Any ideas on
the file being inaccessible?
Marco van de Voort
> post so nobody will WHINE about me "top-posting" (how ridiculous in this
> day and time anyway!), however I've been reading it and the very first
> post in this thread mimics almost EXACTLY the way FPC did on my laptop. I
> have a Linux machine, very old, and it runs FPC just fine "out of the
> box", so to speak. I figured out the -Opentium3 deal, but never saw
> anything else about the fp.cfg file being tied up. After I got that
> message, I went and looked for the file, found it, and tried to open it.
> With the text IDE open, it was declared to be "in use" by Windows, and
> when the IDE was closed the file was released. I can not compile ANYTHING
> through the IDE because of this and was hoping that some kind person would
> address that part of the post.
I do not follow this entirely? Close IDE use textfile to edit fp.cfg, and
run IDE seems to solve that? Or use the IDE to simply correct the parameter?
> The only problem I get on Linux is, when opening the text IDE (both
> machines run 2.2.2, by the way) it really screws with the key bindings for
> ALL consoles, and turns the ESC key into another way to compile while in
> the IDE.
Yes. Known *nix problem (FreeBSD has the same problem btw), physical console
modifications are not on a per console basis. If you don't like the
console programming iirc you can turn it off by running "fp -F".
Besides keyboard settings this also goes for e.g. VGA fonts, bell settings
etc.
IIRC FreeBSD can have different video modes for different ttys, which Linux
also can't, but it's a long time ago that I tried that. (2000 or so)
> That is, unless I use X and start it from an X console window.
> Then it doesn't bother any of the keys,
Hmm, it should work in a console. Sometimes some reconfiguration of the
terminal is needed. Unfortunately, no linux/unix console is the same, and
even the keys available in two different GNome using distributions can vary
due to different defaults for global keys.
> but that's minor compared to the Windows problem. Anyone have a clue why
> the fg.cfg file is being held hostage by the IDE?
It's pretty normal for a file that is kept open read/write. IIRC some kinds
of changes are directly written to the file, not only on close. Also after
the locking program shuts down, a lock can persist for another couple of
seconds.
Maybe the IDE could open the file in sharing compatible mode, but changes in
the textfile wouldn't propagate to the IDE anyway till next start, so I'm
not entirely sure what that actually would fix.
> In Vista, I open a console within Windows, then change to my working dir
> and type the standard 'FP' to start the IDE. It's obviously in need of
> some work, but this is just crazy.
It's the standard console way. Could you elaborate what exactly is crazy
about it? If you want something more GUI, have a look at Lazarus.
> It's really not much more than a glorified Pascal editor when you cannot
> compile through it.
I can compile fine, and fixed the -Opentium without opening the fp.cfg file,
simply corrected it from inside the IDE via "Options-> compiler" and then in
the bottom textfield, I added an extra "p" between -O and pentium3 so that
it reads "-Oppentium3".
> I even looked at file permissions, and after a while I went so far as to
> just move the whole dir structure and try running it from another place,
> but that did squat as well. Any ideas on the file being inaccessible?
Still, I have the feeling there is more to it, and that I'm not
understanding you completely. Could be a vista problem (are you working
somewhere that has special permissions under Vista like c:\program files ?
Please try to describe the problem more, and rant less.
CBFalconer
>
> I deleted the whole post so nobody will WHINE about me
> "top-posting" (how ridiculous in this day and time anyway!),
> however I've been reading it and the very first post in this
> thread mimics almost EXACTLY the way FPC did on my laptop. I
> have a Linux machine, very old,
Totally useless, and unconnected to anything. Do read the
references you have been given.
GMorris
are wondering why they have to scroll through the same
messages endless times to get to the one that matters. If
"top-posting" is the worst thing in your life, you need one.*
Anyway, what I was saying (for those that are interested
and not "anal" about where I WANT to put my post) is
that I cannot compile any programs through the Windows
(yes, Vista) console version of FP. No matter what I do,
it still won't compile through the IDE in Vista. The reason
given is that the fp.cfg is "in use" and it has to be in use BY
the IDE, but still the IDE apparently is trying to open it yet
again for some reason (to compile is what I assume), and
since it already HAS it open, but obviously doesn't seem
to know it, it won't work. I know all about the options
and everything, and I don't edit the config files manually.
It's just that either Vista OR FP will not release the file for
the compiler to read it. I can't figure out if this is a bug in
the IDE code or if it is a Vista thing. If I quit the IDE, I
can compile from the command line OR a makefile, but
with the IDE open you can forget it. Editing, no problem.
Compiling, not happening since the fp.cfg file is tied up by
something. I don't have this in Linux, and can use a console
Window in X to do anything (then it doesn't mess with the
keyboard bindings), so I'm fairly happy with that setup for
now.
The Vista problem is all that's bothering me. I don't get why
the IDE doesn't release the cfg file for the compiler, or at
least share it. I've tried about everything I can think of!
CBFalconer
>
> *I can find just as many resources where OTHER people
> are wondering why they have to scroll through the same
> messages endless times to get to the one that matters. If
> "top-posting" is the worst thing in your life, you need one.*
PLONK.