Re: [fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)
Hans-Peter Diettrich wrote:
Sven Barth schrieb:
On 30.01.2012 20:31, steve smithers wrote:
Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
Existing source code frequently assumes ASCII encoding. The obvious are
upper/lowercase conversions, by and/or or add/sub constant values to
the
characters. It will be hell to find and fix all such code in the
compiler and RTL, even if only the constants have to be modified for
EBCDIC. Even code with the assumed order of common characters (' '<
'0'
< 'A'< 'a') has to be found and fixed manually - how would you even
*find* code with such implicit assumptions?
It does indeed. I am aware of the problems inherent in this. But
the RTL
has to be more or less rewritten anyway to support OS. OS is a very
different
animal to Windows or Linux.
The RTL consists of two parts (though the border is not easily
visible): a platform independant one and a platform dependant one. A
port to a different target normally only includes touching the
platform dependant one, but a port to 370 also requires touching the
platform independant one. This is what DoDi talks about.
It's not anything the compiler could solve. Find out what will happen on
e.g.
for c := 'A' to 'Z' do ...
for c := '0' to 'Z' do ...
(where the literals 'A' etc. could be named constants, or computed values)
With EBCDIC encoding the second loop will never be entered!
@other devs: Could the code page aware AnsiString type be of any help
here?
Only at the I/O side, when files are read/written, or when strings
(filenames!) are sent or received via the OS API. The latter reminds me
of the Windows OEM charset, used in console I/O, which could be
exchanged to mean EBCDIC in IBM consoles.
Unfortunately the Encoding is available only with *strings*, not with
single characters. New types like EBCDICchar could be introduced,
different from AnsiChar, and a directive telling the compiler "literals
are EBCDIC" or "Char is EBCDICchar".
I'd suggest that the thing to do is to first target the compiler at
Linux, i.e. ASCII, hosted on a PC. Once that is adequately working
branch the RTL for EBCDIC, with the intention that this is basically a
set of conversion patches and that the master remains ASCII.
Or of this isn't acceptable because the IBM developers feel we're trying
to force them into our image, let's meet half way and use Solaris which
nobody really enjoys.
--
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] Bounty for MIPS
On 01/30/2012 09:47 PM, Mark Morgan Lloyd wrote: My understanding is that "naked" Flash devices have limited write capability, but that "thumb drives" have an embedded microcontroller that levels the wear. There is still the issue that some filesystems work better with this type of device than others. On naked Flash in fact FAT is very bad (not only) on that behalf, while Linux does provide several file systems that internally do the necessary wear leveling for naked flash chips. The file system issue in fact is one of things the system the wear leveling controller on those drives leverages. But while it improves the wear-out issue greatly, still any flash drive will die once all available spare memory blocks are used up. This is why unnecessary writes should be avoided (e.g. updating the "last read" file-date) AFAIK, all Linux file systems can be configured that way. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bounty for MIPS
On 01/30/2012 06:16 PM, Mark Morgan Lloyd wrote: Presumably for the same reasons that people are trying to translate C to FPGA functionality. NOT that I'm suggesting that as a viable project. There are special "parallel" C dialects that are useful for this. Moreover the most modern way of system design is to do a complete system description (functionality and restrains) in a C like language and have some (expensive) software decide automatically (based on available FPGA resources) what to implement in programmable hardware and what to implement in software, in the end creating compiled files that can be loaded appropriately to get a running system. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPDoc imports
In an attempt to help improve fpdoc I'm blocked in understanding the handling of imported modules. The content files are imported into the link tree, but this tree seems not to be used in finding external identifiers? Instead packages are searched, where I could not yet figure out how these are constructed. When the FCL documentation is created, which imports package (content file) RTL, a package RTL seems to be created, somehow, but its content is not related to the content file. In detail unit System never becomes part of the RTL package? Can somebody explain the creation and population of external packages a bit? What's the purpose of these packages at all, when the essential information about identifiers is contained in the content files? Would it help if I try to create packages from the imports? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)
steve smithers wrote: Mark Morgan Lloyd wrote on Mon, 30 Jan 2012 21:46:28 + Although Linux/390 is closer to what the bulk of us are used to, so please humour us. I am a Linux user so I am sympathetic. It's just that I really don't do development on Linux and am therefore unaware of it's requirements. One question if I may, and I hope this doesn't sound too stupid. When Paul Robinson first raised an S/390 port a few days ago, he proposed using MUSIC/SP as his target operating system. This has the advantages that it's free and has TCP/IP, but the major disadvantage that the prime maintainer is... no longer active. I find it difficult keeping track of things on account of the name changes over the years: what is the situation as regards OS, is there a free version that can be run locally under (e.g.) Hercules, or would anybody who wanted to look at what you were up to have to have a login account on a mainframe somewhere? Or does MUSIC/SP have any/adequate binary compatibility? Why should it sound stupid? I've spent 25 years doing this stuff, I can't reasonably expect everyone else to know how it works. MUSIC/SP as I understand it (from wikipedia I'm afraid) was a proprietry time sharing system writtem by McGill university in the states. It's sole use to us in this discussion was that it had an OS/VS1 emulation mode. OS/VS1 had no terminal based development environment at all (at least not a standard IBM one. It did, later, have systems called TONE and ROSCOE). I think Paul chose this because he either knew it was available or because it was the system he used to use. OS/VS1 has hideous storage limitations by todays standards. However, this emulation mode should give us a good binary comatibilty level storage limitations allowing. I think in the current context the binary compatibility is the important thing. Hercules can run all, or almost all, IBM OS systems. from OS/MFT - OS/MVT from the 1960's up to the latest z/OS 64 bit systems. The problem is with licensing. The ones we can run legally are OS/MFT, OS/MVT, OS/VS2, MVS 3.8 along with various others such as early DOS and VM systems and MUSIC/SP. All of these are free. These, generally, don't have TCP/IP yet, but Hercules provides us with TCP/IP connection using TN3270 (telnet in 3270 mode) so we can use Linux or Windows based terminal emulators such as x3270 to connect to the guests. People are working on a TCP/IP stack for MVS. With the major limitation here that MUSIC/SP- and possibly other operating systems- don't have TCP/IP unless the underlying platform supports IUCV; Hercules (freely available to everyone) doesn't implement IUCV unless VM (not freely available) is running on top of it. Linux appears to get around this restriction by using a simulated SLIP connection. It's also possible to have a logon to a remote MVS system running inside a window running in your favourite web browser. I can't find it on the web at the moment and I don't know what version of MVS it used, but I will keep an eye out for it. But as I understand it JCL is distinct from binary programs- different areas of application, different facilities. On the unix-derived systems that most of us are more used to there is no such distinction: a shell script has access to all the facilities that a binary has, you could (in principle) write a compiler in it. But we don't need to write a compiler, we just need to feed various source programs into a compiler and assemble and linkedit the resulting output with a modicum of "intelligence" to stop on errors. This is what JCL does. Think of it as using a pipe to link the output of one program into the input of another, just not as straightforward. Sorry, you've missed my point. I've come across systems where compilers have to be "blessed" by the local security administrator before they can mark code as executable, and there's a progressively stronger chain up to the point where nobody except that manufacturer can bless a compiler such that it can generate the operating system kernel. The objective is to try to avoid the situation described by Ken Thompson in his 1984 "Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html Unix does not have this mechanism: anybody can build a compiler which can then build a new kernel. -- 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] FPDoc imports
On Tue, 31 Jan 2012, Hans-Peter Diettrich wrote: In an attempt to help improve fpdoc I'm blocked in understanding the handling of imported modules. The content files are imported into the link tree, but this tree seems not to be used in finding external identifiers? The content files are converted to 2 kinds of trees: - A TPasElement tree. - A link tree. The link tree is used in TFPDocEngine.ResolveLink and THTMLWriter.ResolveLinkID The paselement tree is used by the parser to find identifiers (classes mostly, for inheritance trees), so there are less TPasUnsolvedTypeRef instances. Instead packages are searched, where I could not yet figure out how these are constructed. When the FCL documentation is created, which imports package (content file) RTL, a package RTL seems to be created, somehow, but its content is not related to the content file. In detail unit System never becomes part of the RTL package? Can somebody explain the creation and population of external packages a bit? What's the purpose of these packages at all, when the essential information about identifiers is contained in the content files? The purpose is to try and let the parser resolver find identifiers as if they had been parsed. (compare it to the info in a .ppu file) Would it help if I try to create packages from the imports? No. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bounty for MIPS
In our previous episode, Mark Morgan Lloyd said: > capability, but that "thumb drives" have an embedded microcontroller > that levels the wear. There is still the issue that some filesystems > work better with this type of device than others. > > My experience with external USB-connected drives is that their power > demands exceed that of most (internal and external) USB hubs, that they > might not describe themselves accurately to the hub, and that in many > cases they lack an external PSU socket. In practice, the ports on the > back of an NSLU2 "Slug" will drive the notebook-style drives I've got. I've seen 2.5" usb-only HDD's crash laptops, and my experiences with other arm devices (Sheeva, goflex are the same). In short, no devices that don't have an own PSU. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bounty for MIPS
Marco van de Voort schrieb: I've seen 2.5" usb-only HDD's crash laptops, and my experiences with other arm devices (Sheeva, goflex are the same). In short, no devices that don't have an own PSU. My experience is quite different from yours. I've a couple of external 3.5" HHDs with external PSUs, which ceased to work a few days after warranty expired, with a hot cabinet and inoperative HDD, all data lost :-( In contrast none of my external 2.5" HDDs with USB power failed (so far). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc imports
Michael Van Canneyt schrieb: On Tue, 31 Jan 2012, Hans-Peter Diettrich wrote: In an attempt to help improve fpdoc I'm blocked in understanding the handling of imported modules. The content files are imported into the link tree, but this tree seems not to be used in finding external identifiers? The content files are converted to 2 kinds of trees: - A TPasElement tree. - A link tree. The link tree is used in TFPDocEngine.ResolveLink and THTMLWriter.ResolveLinkID The paselement tree is used by the parser to find identifiers (classes mostly, for inheritance trees), so there are less TPasUnsolvedTypeRef instances. This would explain why the System unit never is found - it seems not to contain any classes. Would it help if I try to create packages from the imports? No. Seems like I misinterpreted the many "unit not found" :-( I still wonder why the number of units in the imported RTL package increases over time. Initially it contains 7 modules, and 38 modules in the end, where the RTL currently consists of 46 units. 6 of the initial modules contain classes, but I couldn't find the 7th module "iostream" anywhere, which is the first module in the list. For the input file order: as long as the user has no idea how to order the files, fpdoc should do that for him. Or, in Unix tradition, supply an app that sorts the units ;-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)
Mark Morgan Lloyd schrieb: Sorry, you've missed my point. I've come across systems where compilers have to be "blessed" by the local security administrator before they can mark code as executable, and there's a progressively stronger chain up to the point where nobody except that manufacturer can bless a compiler such that it can generate the operating system kernel. The objective is to try to avoid the situation described by Ken Thompson in his 1984 "Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html Unix does not have this mechanism: anybody can build a compiler which can then build a new kernel. This is how Unix and Linux evolved - everybody could play around with it, and add new functionality. Blaming an compiler for buggy source code IMO helps nothing. Recompiled kernels have to be booted, somehow, what is nothing that ordinary users can do on an mainframe. And when every user must manage his own system(s), what can he do but allow a just installed compiler to do its job? Trusting code is a different thing. With open source code you can be halfways sure that the code has been tested by many people, and MD5 checksums prevent malicious modification of the downloaded sources. This is how malicious modifications, also to the compiler itself, can be detected and avoided. Hackers are kind of evolutionary force, which makes the system software coders aware of backdoors and other flaws. Monetary losses have two benefits: they make intrusions visible, and they enforce improvement of flawed software (to be paid for). Ask companies how much money they invest in safe software, and compare that amount with the (claimed) losses caused by hackers :-] DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc imports
On Tue, 31 Jan 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: On Tue, 31 Jan 2012, Hans-Peter Diettrich wrote: In an attempt to help improve fpdoc I'm blocked in understanding the handling of imported modules. The content files are imported into the link tree, but this tree seems not to be used in finding external identifiers? The content files are converted to 2 kinds of trees: - A TPasElement tree. - A link tree. The link tree is used in TFPDocEngine.ResolveLink and THTMLWriter.ResolveLinkID The paselement tree is used by the parser to find identifiers (classes mostly, for inheritance trees), so there are less TPasUnsolvedTypeRef instances. This would explain why the System unit never is found - it seems not to contain any classes. Would it help if I try to create packages from the imports? No. Seems like I misinterpreted the many "unit not found" :-( Yes. I still wonder why the number of units in the imported RTL package increases over time. Initially it contains 7 modules, and 38 modules in the end, where the RTL currently consists of 46 units. 6 of the initial modules contain classes, but I couldn't find the 7th module "iostream" anywhere, which is the first module in the list. For the input file order: as long as the user has no idea how to order the files, fpdoc should do that for him. Or, in Unix tradition, supply an app that sorts the units ;-) Nono, the parser will need to take care of this. fpdoc is not the only application that uses fcl-passrc. It's planned. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc imports
Am 31.01.2012 14:42, schrieb Hans-Peter Diettrich: Would it help if I try to create packages from the imports? No. Seems like I misinterpreted the many "unit not found" :-( I still wonder why the number of units in the imported RTL package increases over time. Initially it contains 7 modules, and 38 modules in the end, where the RTL currently consists of 46 units. 6 of the initial modules contain classes, but I couldn't find the 7th module "iostream" anywhere, which is the first module in the list. The only "iostream" unit I'm aware of is in packages/fcl-base/src. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)
Hans-Peter Diettrich wrote: Mark Morgan Lloyd schrieb: Sorry, you've missed my point. I've come across systems where compilers have to be "blessed" by the local security administrator before they can mark code as executable, and there's a progressively stronger chain up to the point where nobody except that manufacturer can bless a compiler such that it can generate the operating system kernel. The objective is to try to avoid the situation described by Ken Thompson in his 1984 "Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html Unix does not have this mechanism: anybody can build a compiler which can then build a new kernel. This is how Unix and Linux evolved - everybody could play around with it, and add new functionality. Blaming an compiler for buggy source code IMO helps nothing. Recompiled kernels have to be booted, somehow, what is nothing that ordinary users can do on an mainframe. And when every user must manage his own system(s), what can he do but allow a just installed compiler to do its job? Please note that I'm not being critical, simply attempting to summarise the situation for somebody who might not appreciate the nuances, particularly in view of an earlier comment that it might not be possible to do the final build on a PC. Trusting code is a different thing. With open source code you can be halfways sure that the code has been tested by many people, and MD5 checksums prevent malicious modification of the downloaded sources. This is how malicious modifications, also to the compiler itself, can be detected and avoided. I'm not sure that an authenticate-by-source-digest approach would prevent the sort of problem that Thompson described, unless there was also a mechanism to validate that a particular binary was accurately described by its professed source package. -- 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] Bounty for MIPS
Hans-Peter Diettrich wrote: Marco van de Voort schrieb: I've seen 2.5" usb-only HDD's crash laptops, and my experiences with other arm devices (Sheeva, goflex are the same). In short, no devices that don't have an own PSU. My experience is quite different from yours. I've a couple of external 3.5" HHDs with external PSUs, which ceased to work a few days after warranty expired, with a hot cabinet and inoperative HDD, all data lost :-( The Buffalo I've got here has adequate convection slots, and provision for a clipon fan. In contrast none of my external 2.5" HDDs with USB power failed (so far). I find I've got a (not very fast) laptop which will power an external (Maxtor) 2.5", despite it not working with desktop or server computers or with a commodity hub (I tried earlier). Comparing a USB-connected Buffalo (with its own PSU), USB-connected/powered Maxtor, and internal IDE drive I see hardly any difference in performance when I run my standard "torture test", provided that in all cases the filesystems are ext3. If the filesystem is FAT performance is only 50%. But at the same time at least some Flash storage is known to be optimised for FAT, and reformatting for a different filesystem could impact its lifetime. Trying to drag ourselves back on topic: when it comes to something "unusual" like a MIPS-based board or time on an IBM mainframe, we've just got to make do with what we can get. If a development board has an IDE (PATA/SATA) interface then it's probably worth using, but in all cases we can usefully be aware of the peculiarities of the underlying technology: i.e. whether it risks running hot, takes a lot of current or has constraints on its life. -- 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
