date:20120209


Am 09.02.2012 09:10, schrieb Jy V:

Metro is around the corner,
is there any plan to support the new WinRT coming with Windows 8 ?


WinRT is implemented as a native library which resembles an enhanced 
COM. So one should be able one way or another to implement a binding 
for it. Until someone steps up and implements this binding there won't 
be WinRT support in Free Pascal though.


If you ask whether Lazarus will support WinRT then I advice you to ask 
this on the Lazarus list.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT


Marco van de Voort wrote:

In our previous episode, Hans-Peter Diettrich said:
IMO a more radical solution is desireable, WRT Win9x. Did anybody test 
already, how FPC/Lazarus apps behave on such a system, which does not 
support themes etc., and does not even support Unicode without system 
updates?


I'd split the Win32 target into WinNT (W) and Win9x (A), so that the 
users can decide whether to support Win9x at all.


That depends on decisions still to be made. If we also support 1-byte RTL,
it will still be on the level of winNT.

But I do think that a win9x vs winnt split is unavoidable in time. Specially
since otherwise one gets in the current situation that win9x is occasionally
fixed for a release, but in reality constantly broken in between.


Presumably lumping pre-W2K NT in with '9x. I'm thinking of 
http://mantis.freepascal.org/view.php?id=18803 which wasn't really 
resolved, and which was caused by the return code of a function not 
implemented in older OSes not being checked.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two

2012-02-09 Thread Hans-Peter Diettrich


steve smithers schrieb:


The bit that provides code for VM/SP as opposed to say MVS, is the RTL,
so if I want to open a file, there is a routine in the RTL called OpenFile
(or whatever) that issues the VM code for open.  This lives in System.pp
or Sysfile.pp or whatever it's called in the RTL/VMSP sub-directory

Now, in order for the compiler to function it needs access to a certain
level of base functionality in the VM/SP RTL.


The RTL is compiled before the compiler, so that it can be used inside 
the compiler. This is required for cross-compilation, where the compiler 
has to use the file access routines of the *host* system, and is 
compiled into code for the host system.


The RTL may contain assembler code for the target machine, if you don't 
trust your own compiler to generate appropriate code.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-02-09 Thread Nikolai Zhubr


Hello Florian,
07.02.2012 1:49, Florian Klämpfl:

Am 03.02.2012 01:37, schrieb Nikolai Zhubr:

I can set up ssh
for any FPC developer(s) (though I'll need some time to fix cables etc
then) Let me know.


It would be nice to get an account, currently I'am still busy with
fixing compilation issue but I'd expect first compiled programs within a
few days.


Ok, sorry for delay, I'm now fighting to hook shutdown to front panel 
button, otherwise all seems ready, hopefully it will be online 
permanently starting this weekend, and I'll then mail you login info 
(off list).


Nikolai


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] WinRT support planned ?

2012-02-09 Thread Felipe Monteiro de Carvalho

I am curious as to how exactly it will work. For example: Does it
support overlapping windows or only full screen ones like a mobile
platform?

And how do DirectX applications work there? Also via a DLL together
with WinRT or can one make a native executable with DirectX?

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two


steve smithers wrote:

rvmart...@ntlworld.com wrote on Wed, 8 Feb 2012 14:16:50 + (GMT)


The implementation of calling conventions is up to the code generator as 
well. You can invent your own conventions, and map them to any 
predefined one. As a starting point it's sufficient to support only one 
calling convention, the one for system calls. More conventions for 
calling other external libraries may be required, depending on the 
target OS conventions.

Where can I find details of the input to the back-end?
I'd like to have a crack at generating assembler code for VM/SP. 
 
Maybe I've misunderstood the logic here, but it's my understanding

that the back-end produces assembler statements to produce executable
code for the processor.  So if I want to move something from field a
to field b say, or add two numbers together, the backend generated the
MVC and it's related code or the Add instruction, Handles registers
and addressability and stuff.  Anyway, whatever this stuff is called
it lives in the COMPILER/VMSP (apologies to you case-sensitive types)
sub-directory.

The bit that provides code for VM/SP as opposed to say MVS, is the RTL,
so if I want to open a file, there is a routine in the RTL called OpenFile
(or whatever) that issues the VM code for open.  This lives in System.pp
or Sysfile.pp or whatever it's called in the RTL/VMSP sub-directory

Now, in order for the compiler to function it needs access to a certain
level of base functionality in the VM/SP RTL.  Things like Allocate / 
Deallocate memory, Open and Close a file, Read and Write from and to a

file.  Create and Delete a file etc.  These may, or may not, be written
totally or partially in assembler.


I've added example FPC output at 
http://wiki.lazarus.freepascal.org/ZSeries#Digression:_example_FPC_output 
which might be useful to the current discussion. I've used David Zhang's 
MIPS compiler to do this, since the register etc. model is probably 
closer to zSeries than any of the other v2 compilers.


Note that to get this level of detail the compiler has to be built with 
-dEXTDEBUG in order to enable the -an option, despite the fact that this 
always appears in fpc's -h output. If it were my choice I'd make that 
bit of help output conditional.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

-an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)

On Thu, February 9, 2012 11:49, Mark Morgan Lloyd wrote:
 steve smithers wrote:
 rvmart...@ntlworld.com wrote on Wed, 8 Feb 2012 14:16:50 + (GMT)
 .
 .
 Note that to get this level of detail the compiler has to be built with
 -dEXTDEBUG in order to enable the -an option, despite the fact that this
 always appears in fpc's -h output. If it were my choice I'd make that
 bit of help output conditional.

Making it conditional isn't possible without modifying the structure used
in the message files (plain text files to allow easy translation /
localization to other languages) or their concept / the way how they are
used.

As it works now, the default (English) text file is translated into an
include file containing all texts and compiled into the compiler
executable (but another file with the same structure but written in a
different language may be supplied on the command line and override the
default on run-time). The only conditional parts in the message files are
related to platforms and targets (which is a limited set of dependencies
by definition); -dEXTDEBUG based dependency doesn't fit into that. The
easier solution would be probably adding a note about this dependency
directly into the help page (I or anybody else in the core team can do
that if it really works that way - i.e., if there is no difference between
-an and -a in a compiler compiled without -dEXTDEBUG).

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: -an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)


Tomas Hajny wrote:


Note that to get this level of detail the compiler has to be built with
-dEXTDEBUG in order to enable the -an option, despite the fact that this
always appears in fpc's -h output. If it were my choice I'd make that
bit of help output conditional.


Making it conditional isn't possible without modifying the structure used
in the message files (plain text files to allow easy translation /
localization to other languages) or their concept / the way how they are
used.

As it works now, the default (English) text file is translated into an
include file containing all texts and compiled into the compiler
executable (but another file with the same structure but written in a
different language may be supplied on the command line and override the
default on run-time). The only conditional parts in the message files are
related to platforms and targets (which is a limited set of dependencies
by definition); -dEXTDEBUG based dependency doesn't fit into that. The
easier solution would be probably adding a note about this dependency
directly into the help page (I or anybody else in the core team can do
that if it really works that way - i.e., if there is no difference between
-an and -a in a compiler compiled without -dEXTDEBUG).


Thanks for the expiation :-) Would it be possible to do something like 
(a) annotating non-standard options with e.g. (requires EXTDEBUG) and 
(b) having a line in the banner showing what non-default options were 
used during build?


Free Pascal Compiler version 2.7.1 [2012/02/06] for mipsel
Copyright (c) 1993-2011 by Florian Klaempfl and others
Built with EXTDEBUG, fvm32.
/usr/local/src/fpc/fpc-trunk/compiler/ppcXmipsel [options] inputfile 
[options]

Put + after a boolean switch option to enable it, - to disable it

As a slight aside, I've got a shell script for Linux/Solaris which saves 
this sort of thing and also generates a cross-reference of all files by 
parsing -vt output. I've considered doing something like putting it on 
lazarus-ccr but don't relish handling any why doesn't it work on 
Windows? questions.


Linux pye-dev-07 2.6.38-custom #2 SMP Thu Jun 9 11:07:18 GMT 2011 i686 
GNU/Linux

Using Free Pascal Compiler version 2.7.1 [2012/02/04] for i386
make NOGDB=1 OPT='-O- -gl -vt' all |/usr/local/bin/fpc-filter-vt

= /usr/local/src/fpc/fpc-trunk/rtl/linux/system.pp
+  /lib/ld-linux.so.2

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two


steve smithers wrote:


Regardless of what you may believe, FreePascal is not the first compiler to be
implemented on 370 architecture.  Should I tell tell their developers that 370
architecture is too much like a dinosaur to write a 32 bit compiler.  IBM had 32
bit compilers available in the 1960's.  Should I tell them that the architecture
is broken. It's been around for 50 years and there are hundreds of compilers
available for it.  From FORTRAN to GCC, from COBOL to ADA or from PASCAL/VS to
APL.  All of these were (for the ones that were available from the late
60's) 32 bit compilers.


I feel I have to respond to this after a couple of things I've read over 
the last day or so. I for one have never attempted to belittle big 
iron, since it has always seemed clear to me that that type of kit has 
its uses: if nothing else then to do things like running the name and 
certificate servers that keep distributed systems going. It's also worth 
noting that IBM and Burroughs did engage in controlled decentralisation 
quite early, putting a significant amount of smarts in their terminals 
well in advance of anything done by their trendier competitors such as 
DEC.


In the current case I was relying on the precedent set by the GCC 
porters and the Linux maintainers to say OK, we need to have some 
policy to determine what vintage of hardware is supported. However 
noting the availability of old IBM operating systems and the interest 
people have in running them, and in particular noting the amount of work 
being put into the OS/380 project, I'm fairly rapidly coming to the 
conclusion that the S/370 is worth supporting, even if we brush the 
S/360 under the carpet.


However I'm disturbed by comments like this from the mainflame brigade:

...strong suggestions that IBM should provide their own EBCDIC-based 
operating system and integrated-circuit microprocessor chip for use in 
the IBM Personal Computer as a CICS intelligent terminal (instead of the 
incompatible ASCII-based Intel chip, and immature Microsoft 1980 DOS).


and

Also, the standard character set on the 360/370/Z-System is EBCDIC, 
while the Pentium uses ASCII.


If the community can't get its head around the idea that character 
encoding is much more an operating system than a hardware issue, that 
the Intel/AMD range of processors could happily run an EBCDIC-based 
operating system, and that IBM gleefully supports ASCII-based Linux and 
ASCII-based Internet services then it's going to be damn difficult to 
get this (sub)project off the ground.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT

2012-02-09 Thread Thaddy


On 7-2-2012 12:20, Marco van de Voort wrote:

In our previous episode, Hans-Peter Diettrich said:
That depends on decisions still to be made. If we also support 1-byte 
RTL, it will still be on the level of winNT. But I do think that a 
win9x vs winnt split is unavoidable in time. Specially since otherwise 
one gets in the current situation that win9x is occasionally fixed for 
a release, but in reality constantly broken in between. 
___ fpc-devel maillist - 
fpc-devel@lists.freepascal.org 
http://lists.freepascal.org/mailman/listinfo/fpc-devel 
I do not think that you will break anything if you make W api or A api 
default based on platform. This can be switched in the winapi units. 
That will take little effort, as I explained: we did it already for KOL.





smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two

2012-02-09 Thread rvmartin2

Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote the following on 
09/02/12 14:08:24:

 I feel I have to respond to this after a couple of things I've read over 
 the last day or so. I for one have never attempted to belittle big 
 iron, since it has always seemed clear to me that that type of kit has 
 its uses: if nothing else then to do things like running the name and 
 certificate servers that keep distributed systems going. It's also worth 
 noting that IBM and Burroughs did engage in controlled decentralisation 
 quite early, putting a significant amount of smarts in their terminals 
 well in advance of anything done by their trendier competitors such as 
 DEC.

IBM earned over $15 billion last year from the sale of mainframes.

 In the current case I was relying on the precedent set by the GCC 
 porters and the Linux maintainers to say OK, we need to have some 
 policy to determine what vintage of hardware is supported. However 
 noting the availability of old IBM operating systems and the interest 
 people have in running them, and in particular noting the amount of work 
 being put into the OS/380 project, I'm fairly rapidly coming to the 
 conclusion that the S/370 is worth supporting, even if we brush the 
 S/360 under the carpet.

To an application programmer there is (was?) little difference between 360 and 
370.
 
I'm puzzled by this whole idea of Free Pascal supporting 360/370.
Who is it aimed at?  Who needs it?  
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] WinRT support planned ?


Am 09.02.2012 11:47, schrieb Felipe Monteiro de Carvalho:

I am curious as to how exactly it will work. For example: Does it
support overlapping windows or only full screen ones like a mobile
platform?

And how do DirectX applications work there? Also via a DLL together
with WinRT or can one make a native executable with DirectX?



As I don't know more then I wrote in the previous mail, I'd suggest you 
to wait for the consumer preview that should be published at the end 
of February, then you can play around it yourself ;)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: -an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)

On Thu, February 9, 2012 14:45, Mark Morgan Lloyd wrote:
 Tomas Hajny wrote:

 Note that to get this level of detail the compiler has to be built with
 -dEXTDEBUG in order to enable the -an option, despite the fact that
 this
 always appears in fpc's -h output. If it were my choice I'd make that
 bit of help output conditional.

 Making it conditional isn't possible without modifying the structure
 used
 in the message files (plain text files to allow easy translation /
 localization to other languages) or their concept / the way how they are
 used.

 As it works now, the default (English) text file is translated into an
 include file containing all texts and compiled into the compiler
 executable (but another file with the same structure but written in a
 different language may be supplied on the command line and override the
 default on run-time). The only conditional parts in the message files
 are
 related to platforms and targets (which is a limited set of dependencies
 by definition); -dEXTDEBUG based dependency doesn't fit into that. The
 easier solution would be probably adding a note about this dependency
 directly into the help page (I or anybody else in the core team can do
 that if it really works that way - i.e., if there is no difference
 between
 -an and -a in a compiler compiled without -dEXTDEBUG).

 Thanks for the expiation :-) Would it be possible to do something like
 (a) annotating non-standard options with e.g. (requires EXTDEBUG) and

Yes, this is what I suggested to do above; for -an, not in general,
because I don't know of such dependencies myself (I wasn't aware of it for
-an either).


 (b) having a line in the banner showing what non-default options were
 used during build?

 Free Pascal Compiler version 2.7.1 [2012/02/06] for mipsel
 Copyright (c) 1993-2011 by Florian Klaempfl and others
 Built with EXTDEBUG, fvm32.

I'm afraid that this is a bit more difficult _if_ we want a general
solution. Addressing individual options explicitly is possible (probably
line by line rather than as a list though). Obviously, this wouldn't be a
general solution. However, I'm not aware of any compiler macro allowing to
list all conditional defines (that would be still the easier part, because
these are obviously known within the compiler so adding a new macro should
be possible, but it may be a long list), and even less a macro allowing to
list just compiler defines added explicitly on the command line (rather
than defined internally for a particular target, implied from some other
command line options or defined within the respective source file)... I'd
wait for opinion of other core team members whether we should add support
for explicit Built with EXTDEBUG or do something else (but I'm certainly
not the one who'd add a macro necessary for the general solution).

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two

On Thu, February 9, 2012 15:08, Mark Morgan Lloyd wrote:
 steve smithers wrote:
 .
 .
 Also, the standard character set on the 360/370/Z-System is EBCDIC,
 while the Pentium uses ASCII.

 If the community can't get its head around the idea that character
 encoding is much more an operating system than a hardware issue, that
 the Intel/AMD range of processors could happily run an EBCDIC-based
 operating system, and that IBM gleefully supports ASCII-based Linux and
 ASCII-based Internet services then it's going to be damn difficult to
 get this (sub)project off the ground.

Just a comment on this: While I understand your statement and the Linux
port obviously confirms that an ASCII based operating system is possible
on S370 too, I wouldn't consider the character set being so completely
independent from the underlying hardware (all IBM PC compatible graphic
adapters can show ASCII characters directly but not EBCDIC, and also Intel
CPU instruction set includes support for BCD arithmetics based on the
ASCII character set if I understand it correctly).

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two


Tomas Hajny wrote:

On Thu, February 9, 2012 15:08, Mark Morgan Lloyd wrote:

steve smithers wrote:

 .
 .

Also, the standard character set on the 360/370/Z-System is EBCDIC,
while the Pentium uses ASCII.

If the community can't get its head around the idea that character
encoding is much more an operating system than a hardware issue, that
the Intel/AMD range of processors could happily run an EBCDIC-based
operating system, and that IBM gleefully supports ASCII-based Linux and
ASCII-based Internet services then it's going to be damn difficult to
get this (sub)project off the ground.


Just a comment on this: While I understand your statement and the Linux
port obviously confirms that an ASCII based operating system is possible
on S370 too, I wouldn't consider the character set being so completely
independent from the underlying hardware (all IBM PC compatible graphic
adapters can show ASCII characters directly but not EBCDIC, and also Intel
CPU instruction set includes support for BCD arithmetics based on the
ASCII character set if I understand it correctly).


I agree: when taking terminals and- in the general case- other I/O 
devices into account. But both the examples I gave- one from Wikipaedia 
and the other from Wikibooks- specifically associated ASCII with the CPU 
type (Intel in one case, Pentium in the other) and I really don't 
think that's healthy.


I was just checking the BCD arithmetic situation a few minutes ago, and 
I believe that there's a half carry flag for carry out of the first 
four bits: and that will work equally well for both ASCII and EBCDIC. I 
might have come across other cases, but I can't remember whether they 
apply to x86.


I've worked for a pretty unpleasant mainframe outfit, and am very much 
used to the way that that type of corporation attempts to rewrite 
history to their advantage and forces their position on their employees 
and customers. The company that invented virtual memory and the virtual 
machine to which I added and the intermittent fault... didn't last 
very long, but they had some interesting kit.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: -an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)


Tomas Hajny wrote:


Yes, this is what I suggested to do above; for -an, not in general,
because I don't know of such dependencies myself (I wasn't aware of it for
-an either).



(b) having a line in the banner showing what non-default options were
used during build?

Free Pascal Compiler version 2.7.1 [2012/02/06] for mipsel
Copyright (c) 1993-2011 by Florian Klaempfl and others
Built with EXTDEBUG, fvm32.


I'm afraid that this is a bit more difficult _if_ we want a general
solution. Addressing individual options explicitly is possible (probably
line by line rather than as a list though). Obviously, this wouldn't be a
general solution. However, I'm not aware of any compiler macro allowing to
list all conditional defines (that would be still the easier part, because
these are obviously known within the compiler so adding a new macro should
be possible, but it may be a long list), and even less a macro allowing to
list just compiler defines added explicitly on the command line (rather
than defined internally for a particular target, implied from some other
command line options or defined within the respective source file)... I'd
wait for opinion of other core team members whether we should add support
for explicit Built with EXTDEBUG or do something else (but I'm certainly
not the one who'd add a macro necessary for the general solution).


I suppose another possibility would be to have something in the makefile 
that captured the shell/environment variables, in the same way that the 
Lazarus build captures the revision number if available. But that's not 
in the same league as putting useful info in the banner.


I think a good starting point would be a line that showed any 
definitions that were known to have an effect on the interpretation of 
the options, e.g. EXTDEBUG and- in particular- the exact target CPU when 
this wasn't the default.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two

2012-02-09 Thread steve smithers

Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote on Thu,

steve smithers wrote:

Regardless of what you may believe, FreePascal is not the first compiler to
be
implemented on 370 architecture. Should I tell tell their developers that
370
architecture is too much like a dinosaur to write a 32 bit compiler. IBM
had 32
bit compilers available in the 1960's. Should I tell them that the
architecture
is broken. It's been around for 50 years and there are hundreds of
compilers
available for it. From FORTRAN to GCC, from COBOL to ADA or from PASCAL/VS
to
APL. All of these were (for the ones that were available from the late
60's) 32 bit compilers.

I feel I have to respond to this after a couple of things I've read over
the last day or so. I for one have never attempted to belittle big
iron

I never intended to imply you did. If I failed in this, I apolgise. However
these comments were made by someone. If you look back at the posts from
january you can see them for yourself. It was these posts and their tone
that made me write this mammoth rebuttal. If I'd known how much time that
it would consume, I probably wouldn't have started!

... since it has always seemed clear to me that that type of kit has
its uses: if nothing else then to do things like running the name and
certificate servers that keep distributed systems going.

You might not intend to belittle big-iron, but it is statements such as this
that do just that. There are millions lines of mainframe code out there
written in Cobol or Fortran or, yes, even Assembler that continue to form
the backbone of production systems of most of the big banks and financial
institions, cashpoint networks, supermarket admin systems, travel companies,
sales and administration systems and a host of others. Not to mention the
government!

In the current case I was relying on the precedent set by the GCC
porters and the Linux maintainers to say OK, we need to have some
policy to determine what vintage of hardware is supported.

True. But as I pointed out these systems are produced by IBM. They may
be produced for the open source community, but the bottom line is that
they are there to sell tin. IBM have never really got the idea that there
is more to being a computer company than selling boxes. It is not in their
interest to support old processors.

However
noting the availability of old IBM operating systems and the interest
people have in running them, and in particular noting the amount of work
being put into the OS/380 project, I'm fairly rapidly coming to the
conclusion that the S/370 is worth supporting, even if we brush the
S/360 under the carpet.

However I'm disturbed by comments like this from the mainflame brigade:

I don't care which end it comes from, it is nobodies business what IBM
produce but IBM and their customers. Similarly, I don't give a tinkers
about whether you run MAC OS or Windows or Linux or even Solaris. It's
nobodies business but yours. The same applies to me.

--
Regards
Steve
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two

2012-02-09 Thread rvmartin2

steve smithers ste...@collector.org wrote the following on 09/02/12 18:47:03:

   IBM have never really got the idea that there
 is more to being a computer company than selling boxes. 

That might have been true 20-30 years ago but certainly not now!
Hardware accounted for less than 20% of revenue last year.
The big earner is services.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: -an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)


On 09.02.2012 18:59, Mark Morgan Lloyd wrote:

Tomas Hajny wrote:


Yes, this is what I suggested to do above; for -an, not in general,
because I don't know of such dependencies myself (I wasn't aware of it
for
-an either).



(b) having a line in the banner showing what non-default options were
used during build?

Free Pascal Compiler version 2.7.1 [2012/02/06] for mipsel
Copyright (c) 1993-2011 by Florian Klaempfl and others
Built with EXTDEBUG, fvm32.


I'm afraid that this is a bit more difficult _if_ we want a general
solution. Addressing individual options explicitly is possible (probably
line by line rather than as a list though). Obviously, this wouldn't be a
general solution. However, I'm not aware of any compiler macro
allowing to
list all conditional defines (that would be still the easier part,
because
these are obviously known within the compiler so adding a new macro
should
be possible, but it may be a long list), and even less a macro
allowing to
list just compiler defines added explicitly on the command line (rather
than defined internally for a particular target, implied from some other
command line options or defined within the respective source file)... I'd
wait for opinion of other core team members whether we should add support
for explicit Built with EXTDEBUG or do something else (but I'm
certainly
not the one who'd add a macro necessary for the general solution).


I suppose another possibility would be to have something in the makefile
that captured the shell/environment variables, in the same way that the
Lazarus build captures the revision number if available. But that's not
in the same league as putting useful info in the banner.

I think a good starting point would be a line that showed any
definitions that were known to have an effect on the interpretation of
the options, e.g. EXTDEBUG and- in particular- the exact target CPU when
this wasn't the default.



What about this (using an example application instead of the compiler):

=== source begin ===

program envtest;

const
  crossopt = {$include %CROSSOPT%};
  opt = {$include %OPT%};

begin
  Writeln('CROSSOPT: ', crossopt);
  Writeln('OPT: ', opt);
end.

=== source end ===

The Makefile used below just calls fpc envtest.pp for all.

=== shell begin ===

[sven@artemis oneshots]% make all OPT=-dEXTDEBUG CROSSOPT=-CfSSE2
fpc envtest.pp
Free Pascal Compiler version 2.6.0 [2011/12/23] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for i386
Compiling envtest.pp
Linking envtest
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
10 lines compiled, 0.5 sec
[sven@artemis oneshots]% ./envtest
CROSSOPT: -CfSSE2
OPT: -dEXTDEBUG

=== shell end ===

For the explanation: make moves all variables into the environment which 
is inherited by the processes that are called by it. FPC can include the 
values of a environment variable at compile time (it will be '' if not 
set, though a warning will occur which needs to be disabled with $warn) 
and thus at least the values of OPT and CROSSOPT could be printed by the 
compiler (which should normally be sufficient...).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Episode 4. Addressing and it's limits Part Two

On 9 Feb 12, at 17:47, Mark Morgan Lloyd wrote:
 Tomas Hajny wrote:
  On Thu, February 9, 2012 15:08, Mark Morgan Lloyd wrote:
  steve smithers wrote:
   .
   .
  Also, the standard character set on the 360/370/Z-System is EBCDIC,
  while the Pentium uses ASCII.
 
  If the community can't get its head around the idea that character
  encoding is much more an operating system than a hardware issue, that
  the Intel/AMD range of processors could happily run an EBCDIC-based
  operating system, and that IBM gleefully supports ASCII-based Linux and
  ASCII-based Internet services then it's going to be damn difficult to
  get this (sub)project off the ground.
  
  Just a comment on this: While I understand your statement and the Linux
  port obviously confirms that an ASCII based operating system is possible
  on S370 too, I wouldn't consider the character set being so completely
  independent from the underlying hardware (all IBM PC compatible graphic
  adapters can show ASCII characters directly but not EBCDIC, and also Intel
  CPU instruction set includes support for BCD arithmetics based on the
  ASCII character set if I understand it correctly).
 
 I agree: when taking terminals and- in the general case- other I/O 
 devices into account. But both the examples I gave- one from Wikipaedia 
 and the other from Wikibooks- specifically associated ASCII with the CPU 
 type (Intel in one case, Pentium in the other) and I really don't 
 think that's healthy.
 
 I was just checking the BCD arithmetic situation a few minutes ago, and 
 I believe that there's a half carry flag for carry out of the first 
 four bits: and that will work equally well for both ASCII and EBCDIC. I 
 might have come across other cases, but I can't remember whether they 
 apply to x86.

The Intel x86 (and thus also Pentium) opcodes like AAD (ASCII 
adjust before division), etc., suggest some dependency, but I admit 
that I didn't try to analyze what results it would have with EBCDIC.

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: -an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)


Sven Barth wrote:

On 09.02.2012 18:59, Mark Morgan Lloyd wrote:

Tomas Hajny wrote:


Yes, this is what I suggested to do above; for -an, not in general,
because I don't know of such dependencies myself (I wasn't aware of it
for
-an either).



(b) having a line in the banner showing what non-default options were
used during build?

Free Pascal Compiler version 2.7.1 [2012/02/06] for mipsel
Copyright (c) 1993-2011 by Florian Klaempfl and others
Built with EXTDEBUG, fvm32.


I'm afraid that this is a bit more difficult _if_ we want a general
solution. Addressing individual options explicitly is possible (probably
line by line rather than as a list though). Obviously, this wouldn't 
be a

general solution. However, I'm not aware of any compiler macro
allowing to
list all conditional defines (that would be still the easier part,
because
these are obviously known within the compiler so adding a new macro
should
be possible, but it may be a long list), and even less a macro
allowing to
list just compiler defines added explicitly on the command line (rather
than defined internally for a particular target, implied from some other
command line options or defined within the respective source file)... 
I'd
wait for opinion of other core team members whether we should add 
support

for explicit Built with EXTDEBUG or do something else (but I'm
certainly
not the one who'd add a macro necessary for the general solution).


I suppose another possibility would be to have something in the makefile
that captured the shell/environment variables, in the same way that the
Lazarus build captures the revision number if available. But that's not
in the same league as putting useful info in the banner.

I think a good starting point would be a line that showed any
definitions that were known to have an effect on the interpretation of
the options, e.g. EXTDEBUG and- in particular- the exact target CPU when
this wasn't the default.



What about this (using an example application instead of the compiler):

=== source begin ===

program envtest;

const
  crossopt = {$include %CROSSOPT%};
  opt = {$include %OPT%};

begin
  Writeln('CROSSOPT: ', crossopt);
  Writeln('OPT: ', opt);
end.

=== source end ===

The Makefile used below just calls fpc envtest.pp for all.

=== shell begin ===

[sven@artemis oneshots]% make all OPT=-dEXTDEBUG CROSSOPT=-CfSSE2
fpc envtest.pp
Free Pascal Compiler version 2.6.0 [2011/12/23] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for i386
Compiling envtest.pp
Linking envtest
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
10 lines compiled, 0.5 sec
[sven@artemis oneshots]% ./envtest
CROSSOPT: -CfSSE2
OPT: -dEXTDEBUG

=== shell end ===

For the explanation: make moves all variables into the environment which 
is inherited by the processes that are called by it. FPC can include the 
values of a environment variable at compile time (it will be '' if not 
set, though a warning will occur which needs to be disabled with $warn) 
and thus at least the values of OPT and CROSSOPT could be printed by the 
compiler (which should normally be sufficient...).


One thing I'd caution about the environment is that Debian- and probably 
others- predefines a significant number of shell functions, which shows 
up in the output of the set command.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: -an and help page (Was: Re: [fpc-devel] Re: Episode 4. Addressing and it's limits Part Two)