Got it, thanks!
On Tue, Oct 2, 2018 at 7:57 AM Denis Kozlov wrote:
> PChar is a typed pointer, so you need to point it to the memory location
> of TmpBugStr using the "@" operator, like so:
>
> const
>TempString : PChar = @TmpBugStr;
>
>
> On 01/10/2018 13:18, Ozz Nixon wrote:
>
> Type
>
PChar is a typed pointer, so you need to point it to the memory location
of TmpBugStr using the "@" operator, like so:
const
TempString : PChar = @TmpBugStr;
On 01/10/2018 13:18, Ozz Nixon wrote:
Type
Line:Array[0..127] of Char;
Var
TmpBugStr:Line;
{later in the code}
Const
TempString
If I type Cast TmpBugStr as PChar, then the error gets weird:
Error: Incompatible types: got "SYSTEM.PChar" expected "SYSTEM.PChar"
On Mon, Oct 1, 2018 at 8:20 AM Ozz Nixon wrote:
> See Below - pressed enter too fast:
>
>
> On Mon, Oct 1, 2018 at 8:18 AM Ozz Nixon wrote:
>
>> Type
>>Line:A
See Below - pressed enter too fast:
On Mon, Oct 1, 2018 at 8:18 AM Ozz Nixon wrote:
> Type
>Line:Array[0..127] of Char;
>
> Var
>TmpBugStr:Line;
>
> {later in the code}
> Const
>TempString : PChar = TmpBugStr;
>
>
Error: Incompatible types: got "Line" expected "PChar
Pointing to th
Type
Line:Array[0..127] of Char;
Var
TmpBugStr:Line;
{later in the code}
Const
TempString : PChar = TmpBugStr;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 30/05/17 12:15, Karoly Balogh (Charlie/SGR) wrote:
Is it still required? Darwin does all kinds of weak linking too, and it
has a Pascal written startup code if I'm correct.
We use the libc startup code on Darwin. FPC only supports referencing
external weak symbols. It does not (yet) support
In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > > Err, those are invoked directly from the Makefile, not invoked from inside
> > > FPC. But you're right, that will be also a problem... Some platforms still
> > > use asm-w
Hi,
On Tue, 30 May 2017, Marco van de Voort wrote:
> In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > Err, those are invoked directly from the Makefile, not invoked from inside
> > FPC. But you're right, that will be also a problem... Some platforms still
> > use asm-written startup
In our previous episode, John Paul Adrian Glaubitz said:
> > generate the actual Makefile. But by the time I get there I'll figure it
> > out. One problem at a time.
>
> Actually, the Debian package explicitly regenerates all Makefiles and
> I assume the main reason being to make sure they are up-
In our previous episode, Karoly Balogh (Charlie/SGR) said:
> Err, those are invoked directly from the Makefile, not invoked from inside
> FPC. But you're right, that will be also a problem... Some platforms still
> use asm-written startup stubs in FPC. Not all of them tho'. I think these
> days the
On 05/29/2017 10:22 PM, Florian Klämpfl wrote:
> Well, fpc has a SPARCv9 switch, but it does little to none and it was only
> supposed to enable
> SPARCv9 instructions in 32 bit only mode. SPARC64 is another story: it needs
> some more work, it is
> basically a new target for the compiler though
Am 29.05.2017 um 10:37 schrieb John Paul Adrian Glaubitz:
>> And/or completely unprepared for 64bit in any way.
>
> I actually don't think there would be much work necessary. fpc already
> supports SPARCv9 which is actually by default a 64-bit architecture
> (also known as UltraSPARC).
Well, fpc
Am 29.05.2017 um 17:35 schrieb John Paul Adrian Glaubitz:
> On Mon, May 29, 2017 at 05:11:52PM +0200, Karoly Balogh (Charlie/SGR) wrote:
>> Err, sorry, there's a typo in the previous line I've sent. here's the
>> correct one. Also, ASTARGET= override seems to work, so you don't need to
>> patch the
On 29/05/17 15:15, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for> SPARC, and
regenerate it using fpcmake -Tall. Then everything works. Maybe> it's also possible to just
add AS
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
So Adrian, I've got a question. Looking at fixing this in the right way,
the linker search paths at least.
What's the right directory to search for libs and objects in a
On Mon, May 29, 2017 at 05:55:46PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> From what I can see, binutils 2.9.1, released 1/5/1998 (19+ years ago)
> already has it for SPARC (according to the man page). :) But binutils
> 2.8.1 from 20 years ago, still didn't. So it was added between those
> vers
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > However, it should probably not be merged to fixes, because it may be a
> > breaking change for older Sparc/Linux versions (see my previous e-mail;
> > note that the situation with MIPS was probably different, because the
> > support o
On Mon, May 29, 2017 17:35, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 05:11:52PM +0200, Karoly Balogh (Charlie/SGR)
> wrote:
.
.
>> Now, if you want to patch the compiler for this, or simply wire
>> additional options to the package supplied fpc.cfg with the right
>> paths and op
On Mon, May 29, 2017 at 05:35:37PM +0200, Tomas Hajny wrote:
> However, it should probably not be merged to fixes, because it may be a
> breaking change for older Sparc/Linux versions (see my previous e-mail;
> note that the situation with MIPS was probably different, because the
> support of that
On Mon, May 29, 2017 17:28, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
>
> On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
>
>> Like this:
>>
>> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
>>
>> This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
>> De
On Mon, May 29, 2017 at 05:11:52PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> Err, sorry, there's a typo in the previous line I've sent. here's the
> correct one. Also, ASTARGET= override seems to work, so you don't need to
> patch the sources, you can fix it during build with options.
>
> Like t
On Mon, May 29, 2017 17:17, Karoly Balogh (Charlie/SGR) wrote:
> On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
Hi,
.
.
>> Well, all the -32 options should definitely go into trunk. Upstream
>> doesn't support anything but 32 bits for SPARC anyway and after
>> looking at the rtl/linux/M
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Like this:
>
> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
>
> This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
> Debian SPARC64 box without patching anything.
Just for the record, the same
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > Can you try if you can reproduce this?
>
> Sure. Can you put the cross-compiled ppcsparc somewhere so I can find
> and use it?
You don't need one. :) See my other mail. Although I did crosscompile a
new bootstrap compiler, in the end
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for
> SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe
> it's also possible to just add ASTARGET=-32 into the make command line,
> without patc
On Mon, May 29, 2017 at 04:59:16PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> Did a last attempt, and bingo. :)
Awesome \o/.
> make all OPTS="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
>
> Then everything builds, including the FP IDE, and all tools as expected.
>
> Plus you need to fix the Makefile.f
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> > However, these also seem to be installed in /usr/lib32... So build running
> > now, lets see what happens.
>
> Different error: ... :/ I would gladly keep working on this, but I kinda
> ran out of time for now, I can take a deeper lo
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> However, these also seem to be installed in /usr/lib32... So build running
> now, lets see what happens.
Different error: ... :/ I would gladly keep working on this, but I kinda
ran out of time for now, I can take a deeper look maybe
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> Make sure to pass -L/lib32 to the linker because that's where libc6-sparc
> gets installed into:
>
> root@deb4g:~# dpkg -L libc6-sparc |head
> /.
> /etc
> /etc/ld.so.conf.d
> /etc/ld.so.conf.d/zz_sparc-biarch-compat.conf
> /lib
> /lib32
On Mon, May 29, 2017 at 04:04:00PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > I'll just install that, second.
>
> Oh, ok. Nice. :) I'll wait then.
libc6-sparc was already installed:
root@deb4g:~# apt show libc6-sparc
Package: libc6-sparc
Version: 2.24-10
Priority: optional
Section: libs
Sourc
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > Which is because the buildbox doesn't have these 32bit libraries
> > installed, so FPC obviously cannot link against them. This is because the
> > very limited multiarch you mentioned before I guess. Now, FPC doesn't need
> > Libc on l
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Which is because the buildbox doesn't have these 32bit libraries
> installed, so FPC obviously cannot link against them. This is because the
> very limited multiarch you mentioned before I guess. Now, FPC doesn't need
> Libc on linux f
On Mon, May 29, 2017 at 03:59:37PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> Obviously, the startup compiler doesn't have the -32 fix, so this is why
> it failed for you, but this option inject this option externally.
Ok, I'm an idiot. I completely forgot about fixing the stage0 compiler ...
>
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> In the end, I want to build the Debian package. So, the patches have
> to apply against that version.
Well. I applied a 1 line patch against rtl/linux/Makefile.fpc, to append
-32 when it builds the startup code, regenerated the Makefile
On 05/29/2017 03:20 PM, Karoly Balogh (Charlie/SGR) wrote:
> I'm also sitting in Berlin, so we're having different delusions from the
> heat then... :) BTW, I sent you a pubkey.
But I'm in the south-west of Berlin. Much hotter here :D.
I'll create you an account in a minute.
> It's easy to test
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:57:51PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
> > added -32 into sparc/cpugas.pas file as I said, and from then on I started
> > ge
On Mon, May 29, 2017 at 02:57:51PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
> added -32 into sparc/cpugas.pas file as I said, and from then on I started
> getting 32 bit object files, and after fixing the Makefile, I got a 32
Hi,
On Mon, 29 May 2017, Tomas Hajny wrote:
> > It is, but it's *pregenerated*, and committed to the SVN. The build
> > process doesn't generate any Makefiles, actually. (Lets not argue now it
> > is a nice practice or not, it is what it is...) To fix this, one has to
> > regenerate them. But it'
On Mon, May 29, 2017 14:35, Karoly Balogh (Charlie/SGR) wrote:
.
.
> It is, but it's *pregenerated*, and committed to the SVN. The build
> process doesn't generate any Makefiles, actually. (Lets not argue now it
> is a nice practice or not, it is what it is...) To fix this, one has to
> regenerat
On Mon, May 29, 2017 at 02:35:28PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > But isn't the Makefile generated from fpcmake? :-O
>
> It is, but it's *pregenerated*, and committed to the SVN. The build
> process doesn't generate any Makefiles, actually. (Lets not argue now it
> is a nice practic
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:25:34PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > > > Even passing "-Av8plus" does not help. So, the options from
> > > > compiler/sparc/cpugas.pas are definitely not passed to the assembler.
> >
> > I'm lo
On Mon, May 29, 2017 14:29, John Paul Adrian Glaubitz wrote:
.
.
>> > From the build log:
>> >
>> > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o
>> sparc/prt0.as
>> > as -o
>> /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o
>> sparc/dllprt0.as
>> > as -o
On Mon, May 29, 2017 at 02:31:05PM +0200, Tomas Hajny wrote:
> Are you sure that you rebuilt the compiler completely after your change
> and that you invoked the right (newly built) version while testing the
> performed change? Do you call 'fpc', or 'ppcsparc' while testing it (the
> former may res
On Mon, May 29, 2017 14:14, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote:
>> I tried adding "-32" like this:
>
> Even passing "-Av8plus" does not help. So, the options from
> compiler/sparc/cpugas.pas are definitely not passed to the a
On Mon, May 29, 2017 at 02:25:34PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > > Even passing "-Av8plus" does not help. So, the options from
> > > compiler/sparc/cpugas.pas are definitely not passed to the assembler.
>
> I'm looking into it now. Stay tuned. I managed to reproduce your linker
> p
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:14:26PM +0200, John Paul Adrian Glaubitz wrote:
> > On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote:
> > > I tried adding "-32" like this:
> >
> > Even passing "-Av8plus" does not help
On Mon, May 29, 2017 at 02:14:26PM +0200, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote:
> > I tried adding "-32" like this:
>
> Even passing "-Av8plus" does not help. So, the options from
> compiler/sparc/cpugas.pas are definitely not
On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote:
> I tried adding "-32" like this:
Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debi
On 29/05/17 11:12, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Mon, 29 May 2017, Mark Morgan Lloyd wrote:
My recollection is that the SPARC64 code generator is immature,> hopefully
Jonas will comment on that.
Not sure what "immature" means, granted, I don't know anything aboutSPARC, but
from wh
On Mon, May 29, 2017 at 12:46:57PM +0200, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 11:53:26AM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > > Running the file utility on one of the object files shows that the
> > > assembler did not generate 32-bit code. So, at least a hotfix here
Hi,
On Mon, 29 May 2017, Mark Morgan Lloyd wrote:
> My recollection is that the SPARC64 code generator is immature,
> hopefully Jonas will comment on that.
Not sure what "immature" means, granted, I don't know anything about
SPARC, but from what I see, FPC definitely handles SPARC as a 32bit onl
On Mon, May 29, 2017 at 11:53:26AM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > Running the file utility on one of the object files shows that the
> > assembler did not generate 32-bit code. So, at least a hotfix here
> > would be to pass "-m32" to the assembler.
>
> That is easy to add, see in c
On Mon, May 29, 2017 at 08:45:32AM +, Mark Morgan Lloyd wrote:
> The important thing to know about the linker on 32-bit Solaris is the -Xn
> option to force the native one to be used. Apart from that more info is
> needed before anybody here can comment.
Looking at compiler/system/t_linux.pas,
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> Running the file utility on one of the object files shows that the
> assembler did not generate 32-bit code. So, at least a hotfix here
> would be to pass "-m32" to the assembler.
That is easy to add, see in compiler/sparc/cpugas.pas, M
On Mon, May 29, 2017 at 10:37:42AM +0200, John Paul Adrian Glaubitz wrote:
> > Although we still seem to have a stable 3.0.2 release. Can you try
> > if the stable release built by us works on your system? Any binary
> > from this.
> >
> > ftp://ftp.freepascal.org/pub/fpc/dist/3.0.2/sparc-linux/
>
On 29/05/17 08:15, Karoly Balogh (Charlie/SGR) wrote:
Hi,
On Sun, 28 May 2017, John Paul Adrian Glaubitz wrote:
When trying to cross-build fpc for sparc64, I ran into linker issues. I was> able to
resolve these when changing the ELF format from 32 to 64 bits in>
compiler/system/t_linux.pas and
Hi!
On Mon, May 29, 2017 at 10:03:57AM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > When trying to cross-build fpc for sparc64, I ran into linker issues. I was
> > able to resolve these when changing the ELF format from 32 to 64 bits in
> > compiler/system/t_linux.pas and changing the dynamic loa
Hi,
On Sun, 28 May 2017, John Paul Adrian Glaubitz wrote:
> When trying to cross-build fpc for sparc64, I ran into linker issues. I was
> able to resolve these when changing the ELF format from 32 to 64 bits in
> compiler/system/t_linux.pas and changing the dynamic loader path from
> /lib/ld-linu
Hi!
I'm one of Debian's sparc64 porters and we're currently in the process of
getting the sparc64 port back in shape so it can part of the official release,
superceding Debian's old sparc port.
Naturally, I was trying to bootstrap fpc for Debian/sparc64. However, I noticed
that - despite supporti
Am 17.08.2013 21:31, schrieb Mark Morgan Lloyd:
Bernd Oppolzer wrote:
- first I would like to port the Stanford compiler to Windows, OS/2
and maybe Linux 386,
using FPC. Only phase 1, which generates PCode. My goal is not to get
a compiler
which produces executable code, but to learn about the
Bernd Oppolzer wrote:
- first I would like to port the Stanford compiler to Windows, OS/2 and
maybe Linux 386,
using FPC. Only phase 1, which generates PCode. My goal is not to get a
compiler
which produces executable code, but to learn about the issues when
porting an EBCDIC
compiler to an AS
Sven Barth wrote:
You're telling him that it's possible to build using
...CPU_TARGET=i386 OS_TARGET=linux but where do those come from?
Without being told by a developer or without referring to fully
updated documentation, how does somebody know to use "i386" rather
than "x86", or whether it
Am 25.07.2013 15:12, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 25.07.2013 12:10, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
On 24.07.2013 16:36, Bernd Oppolzer wrote:
Then I built the RTL for linux, which also worked successfully, as
far
as I saw,
but when compiling with -Tlinux, I n
Sven Barth wrote:
Am 25.07.2013 12:10, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
On 24.07.2013 16:36, Bernd Oppolzer wrote:
Then I built the RTL for linux, which also worked successfully, as far
as I saw,
but when compiling with -Tlinux, I now get the following message:
How did you build
On Wed, July 24, 2013 16:36, Bernd Oppolzer wrote:
Hello Bernd,
.
.
> Free Pascal Compiler version 2.7.1 [2013/07/24] for i386
> Copyright (c) 1993-2013 by Florian Klaempfl an
> When trying to build the RTL for OS/2 (running make in the os2 subdir of
fpc/rtl), I get the following messages:
> C
On Wed, July 24, 2013 16:36, Bernd Oppolzer wrote:
Hello Bernd,
.
.
> Free Pascal Compiler version 2.7.1 [2013/07/24] for i386
> Copyright (c) 1993-2013 by Florian Klaempfl an
> When trying to build the RTL for OS/2 (running make in the os2 subdir of
fpc/rtl), I get the following messages:
> C
Am 25.07.2013 12:10, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
On 24.07.2013 16:36, Bernd Oppolzer wrote:
Then I built the RTL for linux, which also worked successfully, as far
as I saw,
but when compiling with -Tlinux, I now get the following message:
How did you build it? Building the RT
Sven Barth wrote:
On 24.07.2013 16:36, Bernd Oppolzer wrote:
Then I built the RTL for linux, which also worked successfully, as far
as I saw,
but when compiling with -Tlinux, I now get the following message:
How did you build it? Building the RTL for Linux should be (assuming
that your FPC so
On 24.07.2013 16:36, Bernd Oppolzer wrote:
Then I built the RTL for linux, which also worked successfully, as far
as I saw,
but when compiling with -Tlinux, I now get the following message:
How did you build it? Building the RTL for Linux should be (assuming
that your FPC source is at c:\fpc)
Thank you very much.
I succeeded in building a new compiler from the SVN sources,
and it runs successfully for the win32 target.
C:\fpc_test>ppc386 pasform.pas
Free Pascal Compiler version 2.7.1 [2013/07/24] for i386
Copyright (c) 1993-2013 by Florian Klaempfl and others
Target OS: Win32 for i38
no problem at all :-)
Am 24.07.2013 14:43, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
We're heading off topic, no disrespect to Bernd intended.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
Sven Barth wrote:
We're heading off topic, no disrespect to Bernd intended.
With the compiler as it stands, I've been able to define e.g.
+ , define a variant constant "reduce", and
then do e.g. a := reduce + b where b is an array. Which was all fine
except that (at least when I last looke
Am 24.07.2013 14:18, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 24.07.2013 12:37, schrieb Mark Morgan Lloyd:
Jonas Maebe wrote:
On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote:
- Stanford Pascal (my version) allows (. .) and (/ /) as
substitutes for [ ]
FPC also supports (. and .). It
Sven Barth wrote:
Am 24.07.2013 12:37, schrieb Mark Morgan Lloyd:
Jonas Maebe wrote:
On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote:
- Stanford Pascal (my version) allows (. .) and (/ /) as substitutes
for [ ]
FPC also supports (. and .). It doesn't support (/ and /) though.
Support for t
Am 24.07.2013 14:12, schrieb Bernd Oppolzer:
Sorry, I'm sure, this is a very basic question,
just to speed up things a little ...
when I run the compiler on Windows on my test sources,
everythings works fine.
Now I wanted to build executables for OS/2 and Linux-386,
just to learn more about cro
Sorry, I'm sure, this is a very basic question,
just to speed up things a little ...
when I run the compiler on Windows on my test sources,
everythings works fine.
Now I wanted to build executables for OS/2 and Linux-386,
just to learn more about cross-compile. But the installed compiler-exe
(wh
Am 24.07.2013 12:37, schrieb Mark Morgan Lloyd:
Jonas Maebe wrote:
On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote:
- Stanford Pascal (my version) allows (. .) and (/ /) as substitutes
for [ ]
FPC also supports (. and .). It doesn't support (/ and /) though.
Support for that could maybe be
Am 24.07.2013 12:13, schrieb Bernd Oppolzer:
Oh, so it is already implemented :-)
same here:
TOF:
1 LINE # D/NEST LVL < STANFORD PASCAL, OPPOLZER VERSION OF
10.2011 >12:07:15 07-24-2013PAGE 1
1 ) program DECOD ( INPUT , OUTPUT ) ;
2 ) (*$
minor correction: the substitute (/ /) is for array indices [ ], not for
comments.
This looks like a matter of taste, but if there were significant amounts of
legacy source code using this, this could be of concern.
(I don't know, if this is the case - I have such programs, because (/ /)
was
a
Jonas Maebe wrote:
On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote:
- Stanford Pascal (my version) allows (. .) and (/ /) as substitutes for [ ]
FPC also supports (. and .). It doesn't support (/ and /) though. Support for
that could maybe be added under a new syntax mode or mode switch swit
Bernd Oppolzer wrote:
Some answers to some questions below:
- the (/ /) substitute for [ ] was the only available substitute in the
original Stanford compiler (which, BTW, is the Pascal P4 of Niklaus Wirth).
I added (. .), because this was present in my sources. Same goes for ->,
Stanford suppor
Oh, so it is already implemented :-)
same here:
TOF:
1 LINE # D/NEST LVL < STANFORD PASCAL, OPPOLZER VERSION OF
10.2011 >12:07:15 07-24-2013PAGE 1
1 ) program DECOD ( INPUT , OUTPUT ) ;
2 ) (*$N+*)
3 ) var I : INTEGER ;
Some answers to some questions below:
- the (/ /) substitute for [ ] was the only available substitute in the
original Stanford compiler (which, BTW, is the Pascal P4 of Niklaus Wirth).
I added (. .), because this was present in my sources. Same goes for ->,
Stanford supported @ only (IIRC).
- t
Am 24.07.2013 11:36, schrieb Bernd Oppolzer:
Yesterday, for example, I observed that even writeln (s); for scalar
types
s is supported - which IMO was not the case for older Pascals - very
convenient for quick tests ...
Free Pascal has vast extensions compared to older Pascal dialects. I
sugges
Am 24.07.2013 03:41, schrieb Bernd Oppolzer:
- when I completed this, I would like to experiment with FPC, trying
to build a compiler
from the source tree, for a new target CPU and OS, that is, IBMZ. I
know enough about
IBM machine code, ASSEMBLER, opsys and run time systems. In contrast
to the
Am 24.07.2013 10:02, schrieb Jonas Maebe:
Comments of different types can be nested;
comments of the same type can be nested, if the compiler option N+ is set.
FPC supports nesting of {} comments. (* *) comments do not nest, and { }
comments appearing inside (* *) comments are ignored (they d
Normally, migrating ASCII sourcecode (be it C or Pascal)
to IBM z is no big deal; you transfer the source to the mainframe
by textmode FTP or similar tools, and everything works fine.
With C in the 90s, there were some issues, because the
C operator characters were at strange places in the differ
Bernd Oppolzer wrote:
- when I completed this, I would like to experiment with FPC, trying to
build a compiler
from the source tree, for a new target CPU and OS, that is, IBMZ. I know
enough about
IBM machine code, ASSEMBLER, opsys and run time systems. In contrast to
the discussions
that I sa
On 24 Jul 2013, at 03:41, Bernd Oppolzer wrote:
> I'm a new member on the fpc-devel mailing list.
Welcome.
> I would like to know, if there are still some efforts going on to
> do a port of FPC on IBMs z architecture. There has been some work
> in this area, although somewhere in the FPC wiki t
Hello,
I'm a new member on the fpc-devel mailing list.
I would like to know, if there are still some efforts going on to
do a port of FPC on IBMs z architecture. There has been some work
in this area, although somewhere in the FPC wiki there are statements
that there will be probably no port to
Felipe Monteiro de Carvalho schrieb:
> On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell wrote:
>> This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
>> very similar to MIPS32 so we might be able to work together on this and
>> the resulting thingy would support both architect
> R01 used by Assembler for optimization (don't use)
> R02 Function Return Value (least significant 32 Bits) (Not used by
> Compiler)
Sorry, Typo: Of course R01 is the one that is not used by the compiler.
-Michael
___
fpc-devel maillist -
Felipe Monteiro de Carvalho wrote:
>
> What operating system will you be targetting?
Linux
>
> I think that telling FPC which ASM instructions to use should be quite
> easy, the main problem should be getting a grip in the binutils, how
> to link libraries and all other stuff that comes with it
Felipe Monteiro de Carvalho wrote:
>
> http://sourceforge.net/projects/fpc-mips/develop
AFAIK, this only contains some initial steps that someone tool ages ago
and did not proceed.
>
> Maybe this work could be ported to the latest trunk.
I have no hope regarding this and suppose to do code for
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell wrote:
> This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
> very similar to MIPS32 so we might be able to work together on this and
> the resulting thingy would support both architectures.
What operating system will you be t
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell wrote:
> This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
> very similar to MIPS32 so we might be able to work together on this and
> the resulting thingy would support both architectures.
I already have 2 news about this.
Here another quote from the said thread:
---
Florian Klaempfl wrote:
Another backend for FPC is 4k-5k lines (pascal, no need to
learn C), just make it a bounty for say 2000 Eur and I'am sure, somebody
will write you a backend for the desired processor.
On 18 Nov 2009, at 11:40, Felipe Monteiro de Carvalho wrote:
How would one proceed to port Free Pascal to a new architecture? Any
initial steps?
Start from an initial backend that is most similar to your cpu. E.g.,
probably ARM or SPARC in your case. Then modify the code.
I haven't found
Felipe Monteiro de Carvalho wrote:
> How would one proceed to port Free Pascal to a new architecture? Any
> initial steps? I haven't found anything about this.
Please take a look at the backlog of this mailing list. It has been
discussed just recently in the "LLVM Backend?" thread and also was
dis
Hello,
How would one proceed to port Free Pascal to a new architecture? Any
initial steps? I haven't found anything about this.
I am considering a MIPS port (to target linux-mips). But don't count
on it, not sure at the moment if it will be successfull.
thanks,
--
Felipe Monteiro de Carvalho
__
1 - 100 of 127 matches
Mail list logo
