I have to admit first, that I did not read all the comments in this
thread. But anyway,
I'd like to comment on this. Because I have done Pascal programming for
almost 40 years
now and even on platforms that are much older than PCs and machines
typically run
by Unix systems, I have a somehow dif
o
- there is no declaration for the -> CHAIN pointer type, nowhere
- it is even possible to use it in the CFORW record, prior to the
definition of CHAIN
(those forward references are checked later)
Kind regards
Bernd
Am 10.06.2019 um 03:26 schrieb Ben Grasset:
On Sun, Jun 9, 2019 at 8
Am 10.06.2019 um 00:28 schrieb Ben Grasset:
On Sun, Jun 9, 2019 at 11:26 AM Florian Klämpfl
mailto:flor...@freepascal.org>> wrote:
Yes, but this has *nothing* to do with the output of -vp. Nothing.
My point with that was more just getting at "clearly typed pointer
aliases are not actuall
No,
if you put a semicolon in there, you will get wrong syntax,
no matter what the datatype is.
Example:
{$MACRO ON}
{$define Fifteen:=15;}
{$define Twelve:=12;}
...
if HDCOUNT0 >= COUNT0 then X := Fifteen
else X := Twelve;
will generate this Pascal statement:
if HDCOUNT0
Hi Guiliano,
I'm no FPC macro language wizard, but in my believe
you are replacing Positiva with False, followed by a semicolon,
and so you get the error from the compiler.
{$define Positiva:=False}
should probably work.
HTH,
kind regards
Bernd
Am 12.04.2017 um 19:39 schrieb Giuliano Colla:
Jonas Maebe schrieb:
On 14/01/16 17:45, Mathias wrote:
The code is machine generated.
I wanted to test which compiler is faster, the. Of FPC or C ++
C ++ could compile the code without errors.
Whether or not it can be compiled is unrelated to the language of
course, but to the compiler. We in
Am 17.12.2014 22:37, schrieb Ralf Quint:
On 12/17/2014 12:38 PM, rpzrpz...@gmail.com wrote:
Ralf, Such passion for obsolescence...
Thanks!
What is the use case other than a hobby and pride for OS/2 support?
What ever the user wants to do! Who are you to tell other people what
is a valid use
Am 26.09.2013 22:33, schrieb Tomas Hajny:
How much does the 386 CPU with 2 MB of appropriate RAM cost today? How
much power and cooling does it need? How much reliable would be the HW
compared to more up to date alternatives (let's say ARM or MIPS with 512
MB RAM and an SSD running Linux)?
Anyw
Am 26.09.2013 11:07, schrieb Tomas Hajny:
Here the old style ("light weight" / "internal" multi-thread enabled)
pthread lib might help. Supposedly same does not need to be "installed"
but could be statically linked to.
You can run another operating system on top of DOS (that's basically what
DOS
Am 03.09.2013 08:45, schrieb Mark Morgan Lloyd:
if you have a language like C which doesn't support nested procedure
definitions,
it's perfectly simple. You can reach the local (auto) variables using
register R13, and
the parameters using R1. You only need another register to access the
stati
Am 02.09.2013 10:37, schrieb Mark Morgan Lloyd:
That's obviously far friendlier to a language like Pascal than the
examples in most assembler-level treatises- I wonder how compatible it
is with the description of the Linux ABI informally at
http://linuxvm.org/present/SHARE99/S8139db.pdf ?
Am 01.09.2013 21:42, schrieb Mark Morgan Lloyd:
No, I meant that Bernd suggested R1 earlier as a simulated stack
pointer. Does IBM use R1 for this on variants of the architecture that
have push/pop opcodes, or some other general-purpose register, or a
dedicated register?
R1 was only meant
Am 01.09.2013 20:30, schrieb Mark Morgan Lloyd:
The problem here is that compiler design has moved on a lot since
Wirth's day. It's not difficult to write a compiler using e.g.
recursive descent or Meta-II which emits instructions for an abstract
stack-based machine, and that might be a good
Am 01.09.2013 19:40, schrieb Mark Morgan Lloyd:
At this point I'd throw in that one of the things the higher levels of
the compiler knows is the overall properties of the registers, i.e.
things like which ones are available for procedure parameters. This is
one of the things that the lower leve
Am 01.09.2013 18:01, schrieb Florian Klämpfl:
Am 01.09.2013 16:55, schrieb Bernd Oppolzer:
No need to answer to that ... I understood in the meantime that FPC does
NOT rely on
PUSH and POP instructions. Instead the linear assembler representation
is already fully
CPU specific.
(which makes
No need to answer to that ... I understood in the meantime that FPC does
NOT rely on
PUSH and POP instructions. Instead the linear assembler representation
is already fully
CPU specific.
(which makes porting a bigger effort)
Kind regards
Bernd
Am 01.09.2013 16:39, schrieb Bernd Oppolzer
Am 01.09.2013 16:12, schrieb Jonas Maebe:
So my question is: is it possible to modify the outcome of step 2 (the linear
assembler representation) depending on the target platform
The linear assembler representation is already 100% platform-specific (as Sven
mentioned above). FPC does not have
Am 01.09.2013 16:02, schrieb Mark Morgan Lloyd:
Bernd Oppolzer wrote:
I'm about to head out, so have to be extremely brief.
Thank you very much for that, that made things much clearer for me.
So the compiler relies heavily on the external assembler and the
syntax it supports,
as long a
Am 01.09.2013 12:26, schrieb Sven Barth:
If someone wants to port the compiler to a new target processor it is
advisable to look whether there exists an OS that is already supported
by FPC, because then "only" the code generator and the CPU specific
parts of the RTL need to be implemented whi
Am 21.08.2013 22:17, schrieb Steve:
Mark Morgan Lloyd wrote
> Otherwise we also rely on external tools (mostly the GNU linker)
> here. So as a first step you'd choose the approach of using an
> external assembler and linker, because simply calling a third party
> utility is easier than complete
Am 20.08.2013 16:54, schrieb Mark Morgan Lloyd:
> Just to name a few: you'll need to get parameter passing for functions
> correctly
Which leads to another issue: the 370 is a register-based system
without a stack as understood today. Parameters are mostly passed in
registers, but this is larg
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
now able
to build a new compiler from the compiler sources.
Kind regards
Bernd
Am 24.07.2013 14:19, schrieb Sven Barth:
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 t
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
le to build a compiler that is able to build
different targets at the same time?
Kind regards
Bernd
Am 24.07.2013 11:46, schrieb Sven Barth:
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
years old when
I started
Pascal programming on this machine, today I'm 54).
-> is a substitute for the pointer symbol; other symbols used for this
are ^ and @
Kind regards
Bernd
Am 24.07.2013 12:37, schrieb Mark Morgan Lloyd:
Jonas Maebe wrote:
On 24 Jul 2013, at 03:41, Bernd O
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
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
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
30 matches
Mail list logo
