On Wed, January 18, 2012 17:32, Felipe Monteiro de Carvalho wrote:
> 2012/1/18 Tomas Hajny :
>> As pointed out in my other e-mail, "everywhere necessary" implies either
>> "dear user, convert all your files from the original encoding before you
>> want programs created in FPC to touch them"
>
> Yes
Felipe Monteiro de Carvalho wrote:
2012/1/18 Tomas Hajny :
As pointed out in my other e-mail, "everywhere necessary" implies either
"dear user, convert all your files from the original encoding before you
want programs created in FPC to touch them"
Yes, no problem here. I assume there must be
Hi,
On Wed, 2012-01-18 at 15:17 +0200, Žilvinas Ledas wrote:
> On 2012-01-18 15:08, Gennadiy Poryev wrote:
> >> Do you think it's granted that there is only one return in a function ?
> >> Maybe optimization or "exit" could create additional returns
> > Actually I do. Because I write this functio
Am 18.01.2012 16:58, schrieb Jonas Maebe:
Then there is the second part of this inquiry which is:
$CROSS - various options I haven't decided yet
A most desperately missing feature - Cross Reference generation. I can
always write a cross-reference program, and in fact I'm working on one
because
On Wed, January 18, 2012 16:51, Mark Morgan Lloyd wrote:
> Sven Barth wrote:
>
>>> Perhaps now would be a good time for a core developer to add
>>> appropriate
>>> definitions to trunk, so that anybody working on the IBM port only
>>> needs
>>> to modify files in a directory off ./compiler.
>>
>> W
2012/1/18 Tomas Hajny :
> As pointed out in my other e-mail, "everywhere necessary" implies either
> "dear user, convert all your files from the original encoding before you
> want programs created in FPC to touch them"
Yes, no problem here. I assume there must be some program in this
platform whi
On Wed, January 18, 2012 11:22, Felipe Monteiro de Carvalho wrote:
> 2012/1/18 Tomas Hajny :
>> ...except for the EBCDIC stuff, because the common parts of our RTL
>> assume
>> ASCII in many places
>
> If it was me implementing I would simply convert between both types
> everywhere necessary and le
On 18 Jan 2012, at 01:07, Paul Robinson wrote:
I would like to ask whether there's a rule or policy on new compiler
directives.
In general: the fewer, the merrier :)
The new directives are first, for printing capability:
Printing-related features is not something that we'd ordinarily put
Sven Barth wrote:
Perhaps now would be a good time for a core developer to add appropriate
definitions to trunk, so that anybody working on the IBM port only needs
to modify files in a directory off ./compiler.
What kind of definitons do you think of?
Absolute minimum, probably mostly makef
Am 18.01.2012 12:51, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
1.
You wrote that you use the source code of FPC 2.6.0 and copied the
"compiler" and "rtl" directories to some other "workplace". I suggest
you to use a SVN checkout of the development version (you can find the
links here:
Am 18.01.2012 12:27, schrieb Mark Morgan Lloyd:
I noticed that you wanted to add a unit "i_i370" to the "compiler"
unit and to the directory "systems". This is wrong. The units listed
in the "compiler" unit are the target operating systems (e.g. Windows,
Linux, DOS), not the underlying architectu
Am 18.01.2012 14:08, schrieb Mark Morgan Lloyd:
Tomas Hajny wrote:
I can't remember the source, but my understanding is that Wirth
originally worked with an IBM 029 keypunch, possibly connected preparing
decks for a CDC. He specifically defined (* and *) as digraphs for { and
}, and I think the
2012/1/18 Tomas Hajny :
> ...except for the EBCDIC stuff, because the common parts of our RTL assume
> ASCII in many places
If it was me implementing I would simply convert between both types
everywhere necessary and leave the RTL using ASCII.
--
Felipe Monteiro de Carvalho
_
On Wed, January 18, 2012 13:56, michael.vancann...@wisa.be wrote:
> On Wed, 18 Jan 2012, Tomas Hajny wrote:
>
>>> But then you are assuming the RTL should be using EBCDIC internally as
>>> well ?
>>> Obviously, that will be a lot more work.
>>>
>>> But I don't think this should be so.
>>
>> I may b
On 2012-01-18 15:08, Gennadiy Poryev wrote:
Do you think it's granted that there is only one return in a function ?
Maybe optimization or "exit" could create additional returns
Actually I do. Because I write this function :)
It uses quite a lot of loops and ifs, but no exits.
And what I need is
> Do you think it's granted that there is only one return in a function ?
> Maybe optimization or "exit" could create additional returns
Actually I do. Because I write this function :)
It uses quite a lot of loops and ifs, but no exits.
And what I need is a reliable way to get its code size at run
Tomas Hajny wrote:
I can't remember the source, but my understanding is that Wirth
originally worked with an IBM 029 keypunch, possibly connected preparing
decks for a CDC. He specifically defined (* and *) as digraphs for { and
}, and I think there were others including (. and .) for [ and ] Di
Do you think it's granted that there is only one return in a function ?
Maybe optimization or "exit" could create additional returns
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-dev
Hi all,
In my project (win32) I need to estimate the number of machine code bytes of a
certain function.
The most straightforward option was to look for $c3 which is ret, and it worked
on optimization levels O0 and O1. O2 and O3 seem to prefer $c2 $04 $00 (retn 4)
instead.
Then here comes win6
On Wed, 18 Jan 2012, Tomas Hajny wrote:
But then you are assuming the RTL should be using EBCDIC internally as
well ?
Obviously, that will be a lot more work.
But I don't think this should be so.
I may be overlooking something, of course. However: Our RTL is based on
common (target specific
On Wed, January 18, 2012 13:14, Mark Morgan Lloyd wrote:
> Tomas Hajny wrote:
>
>> is nothing like translation between ASCII and EBCDIC because there are
>> multiple different character sets for both and real conversion isn't
>> possible without taking this into account and knowing the real charact
On 18 Jan 2012, at 13:32, Alexey Voychehovich wrote:
http://bugs.freepascal.org/view.php?id=2
like this?
Yes, thanks.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
http://bugs.freepascal.org/view.php?id=2
like this?
On Wed, Jan 18, 2012 at 2:24 PM, Jonas Maebe wrote:
>
> On 18 Jan 2012, at 13:16, Alexey Voychehovich wrote:
>
> you are change the code? or me send patch again?
>
>
> It's best to submit patches
> via http://bugs.freepascal.org/set_project.
On 18 Jan 2012, at 13:16, Alexey Voychehovich wrote:
you are change the code? or me send patch again?
It's best to submit patches via http://bugs.freepascal.org/set_project.php?project_id=6
, then they can't be forgotten.
Jonas___
fpc-devel mai
you are change the code? or me send patch again?
On Wed, Jan 18, 2012 at 2:10 PM, Jonas Maebe wrote:
>
> On 18 Jan 2012, at 13:01, Alexey Voychehovich wrote:
>
> patch for http://svn.freepascal.org/svn/fpc/trunk/packages/imagemagick
>
> Small fix for build in Delphi
>
>
> You can use {$z4}, that
Tomas Hajny wrote:
is nothing like translation between ASCII and EBCDIC because there are
multiple different character sets for both and real conversion isn't
possible without taking this into account and knowing the real character
sets which again depends on the context which is again not known
On 18 Jan 2012, at 13:01, Alexey Voychehovich wrote:
patch for http://svn.freepascal.org/svn/fpc/trunk/packages/imagemagick
Small fix for build in Delphi
You can use {$z4}, that works both in FPC and in Delphi.
Jonas___
fpc-devel maillist - fpc
Sven Barth schrieb:
1.
You wrote that you use the source code of FPC 2.6.0 and copied the
"compiler" and "rtl" directories to some other "workplace". I suggest
you to use a SVN checkout of the development version (you can find the
links here: http://www.freepascal.org/develop.var (at "Connec
? It just means you must convert ascii to ebcdic in OS calls that require
strings. All these calls must be re-implemented anyway, so a generic
routine
to do this conversion seems like the obvious path. I doubt this will be
the
real bottleneck :-)
It should not be a bottleneck, but I'm afraid t
Hi
patch for http://svn.freepascal.org/svn/fpc/trunk/packages/imagemagick
Small fix for build in Delphi
--
Don`t drink and drive, smoke and fly!
12.patch
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.
Hello everyone.
I am trying to port a set of Delphi libraries to FPC and during
compilation from the Lazarus IDE I get a "Compilation aborted" without
any other explanation. Doing the build from a command prompt I get
this:
Compiling unit1.pas
Compiling C:\Projects\MkCtrls\PropStorage.pas
Compili
On Wed, January 18, 2012 11:57, michael.vancann...@wisa.be wrote:
> On Wed, 18 Jan 2012, Tomas Hajny wrote:
>> On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
>>> On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
> O
Sven Barth wrote:
You wrote that you use the source code of FPC 2.6.0 and copied the
"compiler" and "rtl" directories to some other "workplace". I suggest
you to use a SVN checkout of the development version (you can find the
links here: http://www.freepascal.org/develop.var (at "Connect to So
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code
michael.vancann...@wisa.be wrote:
? It just means you must convert ascii to ebcdic in OS calls that require
strings. All these calls must be re-implemented anyway, so a generic
routine
to do this conversion seems like the obvious path. I doubt this will be the
real bottleneck :-)
Would you l
On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
> On Wed, 18 Jan 2012, Tomas Hajny wrote:
>> On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
>>> On Wed, 18 Jan 2012, Michael Schnell wrote:
>>>
AFAI learned:
I suppose the code generator should be doable,
Am 17.01.2012 21:52, schrieb Paul Robinson:
From: Paul Robinson
As has probably been a bit of a scare to some people, I've more-or-less
"unofficially announced" by putting up an article on the Free Pascal Wiki
regarding how I've decided I am going to work on porting the Free Pascal compiler to
michael.vancann...@wisa.be wrote:
As for using Linux: I have no idea how this works in practice, so I can't
comment on that. I know that people here use Hercules inside linux to
develop for zSeries, but then again running a linux inside that seems a
bit like overkill :-)
It's trivial and perf
Tomas Hajny wrote:
...except for the EBCDIC stuff, because the common parts of our RTL assume
ASCII in many places (most of them probably not that difficult to fix by
adding some platform specific constants changing the behaviour from ASCII
only to consider EBCDIC too, but scattered around many
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there
already
are several supported CPUs. At least a working comp
On 01/18/2012 10:51 AM, Tomas Hajny wrote:
Still, starting with the Linux for S/390...
A nice thing being that - AFAI read - the more recent versions of the
OS allow for starting multiple virtualized Linux instances.
-Michael
___
fpc-devel mailli
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
> On Wed, 18 Jan 2012, Michael Schnell wrote:
>
>> AFAI learned:
>> I suppose the code generator should be doable, regarding that there
>> already
>> are several supported CPUs. At least a working compiler might come into
>> existenc
michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there
already are several supported CPUs. At least a working compiler might
come into existence in a decent amount of time, adding optimiza
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there already
are several supported CPUs. At least a working compiler might come into
existence in a decent amount of time, adding optimizations is another
project.
OTOH
AFAI learned:
I suppose the code generator should be doable, regarding that there
already are several supported CPUs. At least a working compiler might
come into existence in a decent amount of time, adding optimizations is
another project.
OTOH I suppose that a porting the RTL to a mainframe
45 matches
Mail list logo
