Re: [fpc-devel] Purpose of uses ... in?
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote: Jonas Maebe schrieb: That is incorrect. Relative file names do work. They are resolved relative to the current working directory of the compiler. So what's the current working directory? The current directory when the compiler was started. E.g.: c:\pp\src ppc386 project\test.pas - c:\pp\src is the current working directory (aka present working directory). Sorry, I don't understand this strange convention :-( How can the user of a project know, from which directory a project must be compiled, so that the relative pathes are resolved as the project author had in mind? How in detail does Lazarus know that? But it would explain why my relative unit was not found :-( Does this mean that whole projects are recompiled, when only the compiler is invoked from a different directory, so that relative pathes are re-evaluated properly? Of course. This is normal ? The compiler may find a whole different set of units if unit paths are relative. It may find units it didn't find in the first place. That's why I would restrict the usage of in, with a (relative) path, to a program or library module, as AFAIR Delphi does, and make the directory of that file the root for relative filenames. In other units a relative path, based on an arbitrary working directory, can only lead to confusion, when the using unit is compiled for different projects - except when the directory of the using unit itself is used to resolve relative filenames in its uses clauses. 'in' is only allowed in projects, libraries and packages. Anything else will lead to confusion. In other units it may be helpful when the filename can be overridden (alias feature). Then it's easy to exchange qualified references, by only changing the unit name in the uses clause, instead of editing all occurences of the unit name in the remainder of the code. But this is not a frequently required feature, so that in filespec simply could be ignored (or disallowed) in ordinary units. It must be disallowed. It will only be a source of frustration. The 'in' feature was introduced by borland because they made the mistake of using the main program file as project files. In later versions they corrected this, but the damage was done. The unit alias feature was introduced to ease transition from TP for windows to Delphi. So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place. I would not encourage it's use; the proper way to instruct the compiler where to look for units is using the -Fu switch. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Op 2010-07-11 15:47, Hans-Peter Diettrich het geskryf: I know that the in filespec is part of the Delphi syntax, but what is it really good for? As far as I know, it was introduced in Delphi/Kylix to notify the IDE of what units are part of the project. Instead, Lazarus IDE does this with .lpi files, fpGUI IDE with .project files and MSEide with .prj files. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
In our previous episode, Hans-Peter Diettrich said: That's why I would restrict the usage of in, with a (relative) path, to a program or library module, as AFAIR Delphi does, and make the directory of that file the root for relative filenames. AFAIK it does not. Delphi projects with relative paths in library searchnames also can go horribly wrong. Usually the working dir is equal to the project dir, but in some cases they can differ, and then it goes wrong. The IN syntax was iirc mainly to fix certain Kylix naming issues, and to assist the designer (hence its main use in .dpr). It was abused for all kinds of trickery, but these were always hacks afaik. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Op 2010-07-12 09:01, Marco van de Voort het geskryf: The IN syntax was iirc mainly to fix certain Kylix naming issues, and to assist the designer (hence its main use in .dpr). As far as I know the in syntax was used in Delphi .dpr files, long before Kylix arrived. It was initially used by Delphi to know which files are part of a project. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Jonas Maebe schrieb: I know that the in filespec is part of the Delphi syntax, but what is it really good for? AFAIK it's not allowed to rename units this way, and since (currently) only absolute filenames are implemented, That is incorrect. Relative file names do work. They are resolved relative to the current working directory of the compiler. Clarification: When I start compiler\prep.lpi from Lazarus, the current directory is set to compiler\i386\, that's why compiler\prep.pas is not found. After several tries and discussions I found that this is just the directory of the *executable*, not of the project. This is documented behaviour, but one must understand the difference between the Lazarus IDE working directory (project) and the runtime working directory (executable). Sorry for the confusion :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
On 07/10/2010 12:40 PM, Hans-Peter Diettrich wrote: Let me know if you (or somebody else) has more concrete plans on the integration of a new CPU. I remember some discussions about doing a MIPS / PIC32 port recently I just stripped down the machine files for a no_cpu machine (all fakes), with some documentation about the required units etc. Is this based on what we already have for X86, ARM, etc, or does it fork to another set of ARC implementations ? If fork, is it intended / viable to move the existing implementations into that scheme ? An implementation of a new CPU, based on that skeleton, would rise the priority for further explorations and documentation. No idea in what state the structure / documentation of the existing fully supported implementations such as x86 and ARM is. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
On 07/11/2010 03:29 PM, Hans-Peter Diettrich wrote: Further projects could implement additional front-ends for FPC, for other Wirthian languages (ISO-Pascal, Modula, Oberon...). IMHO a lot more interesting than ISO-Pascal, Modula, Oberon: What about Delphi-Prism on that behalf. ? (This supposedly would be easier to make working using a .NET/MONO-code generating backend compiler than by attempting to reproduce the appropriate functionality as far as viable such as parallel in the RTL.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
In our previous episode, Michael Schnell said: What about Delphi-Prism on that behalf. ? If it relies on GC (and afaik Oberon has the same problem), an RTL based on GC first has to be explored first, and the extend of the changes. But more importantly, what would be the use of supporting Prism? (This supposedly would be easier to make working using a .NET/MONO-code generating backend compiler than by attempting to reproduce the appropriate functionality as far as viable such as parallel in the RTL.) If you want paralel, take vector pascal, and implement it in e.g. the FPC or objfpc dialect. Implementing the whole of Prism and its extensive baggage for just that is insane. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
On 07/12/2010 11:51 AM, Marco van de Voort wrote: But more importantly, what would be the use of supporting Prism? Before bashing me: I don _not_ vote for starting this really huge project, but nonetheless I think it would be great to have. (1) Delphi Prism adds a lot of interesting language constructs such as parallel execution. Of course with Prism this is done using the .NET infrastructure, but such things of course also can be implemented in the RTL so that a native compiler could handle it. (No comment regarding garbage collection etc, as this already was mentioned by the Hans-Peter regarding Oberon.) (2) I feel that using .NET / Mono as an architecture to compile to, would be a great addition, too, and while it's not viable with the native Pascal dialect, Prism takes care of presenting the paradigms decently to the programmer. If you want paralel, take vector pascal, and implement it in e.g. the FPC or objfpc dialect. I suppose this is a good idea, even tough I suppose that the .Net parallel paradigm is a lot more broadly known than that of Vector Pascal. so Hans-Peter might want to add VP to his list. Moreover parallel only is one example of Prism goodies that might be great to have. Implementing the whole of Prism and its extensive baggage for just that is insane. Agreed. In fact I doubt that there will be enough manpower available in the community to start such a project with the hope to get Beta state in a decent amount of time. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On 07/11/2010 11:31 PM, Michael Müller wrote: We use relative paths like '..\foo\foo.pas' or '..\..\foo\foo.pas' under Windows and it works with FPC 2.4.0 (but it already worked with 2.2.4). Portability nightmare . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote: So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place. It could be made useful when - it takes precedence above the search path - can bed used relative with current = the file it is read from - there is an OS independent syntax (does using / and \ both as separators make sense ? ) - the (Lazarus-.usual) Variables to things like project path are usable - ... ??? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Op Mon, 12 Jul 2010, schreef Michael Schnell: On 07/12/2010 08:12 AM, Michael Van Canneyt wrote: So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place. It could be made useful when You may be able to make it more usefull, but there still is no justification for its existance. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Mon, 12 Jul 2010, Michael Schnell wrote: On 07/12/2010 08:12 AM, Michael Van Canneyt wrote: So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place. It could be made useful when - it takes precedence above the search path - can bed used relative with current = the file it is read from - there is an OS independent syntax (does using / and \ both as separators make sense ? ) - the (Lazarus-.usual) Variables to things like project path are usable - ... ??? The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible. Bottom line is: don't use 'in' for the uses clause; use the command-line option to specify the location of the sources. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On 07/12/2010 01:32 PM, Michael Van Canneyt wrote: The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible. Right you are. I was just trying to help ;). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
In our previous episode, Michael Schnell said: On 07/12/2010 11:51 AM, Marco van de Voort wrote: But more importantly, what would be the use of supporting Prism? Before bashing me: I don _not_ vote for starting this really huge project, but nonetheless I think it would be great to have. It is not bashing. It is stimulating you to come up with something better than pointing at some isolated syntax like paralel as motivation to support an hugely complex framework that involves frontend, backend AND libraries. The question is if the implementation even survived the move from a managed GCed environment to a native non-GC one. (1) Delphi Prism adds a lot of interesting language constructs such as parallel execution. Of course with Prism this is done using the .NET infrastructure, but such things of course also can be implemented in the RTL so that a native compiler could handle it. (No comment regarding garbage collection etc, as this already was mentioned by the Hans-Peter regarding Oberon.) (2) I feel that using .NET / Mono as an architecture to compile to, would be a great addition, too, and while it's not viable with the native Pascal dialect, Prism takes care of presenting the paradigms decently to the programmer. But why? What does it make possible? What would you use it for in practice, that you can't use Prism+mono for? (not the ideal case of just press the button and recompile, and slap mono under it, but a realistic scenario, with incompatibilities, version lag etc, several years to implement, at which point Prism maybe already is canned) Prism is not horrible expensive like Delphi, and can sometimes be had for $99. If you want paralel, take vector pascal, and implement it in e.g. the FPC or objfpc dialect. I suppose this is a good idea, even tough I suppose that the .Net parallel paradigm is a lot more broadly known than that of Vector Pascal. so Hans-Peter might want to add VP to his list. Moreover parallel only is one example of Prism goodies that might be great to have. Like what? As said, parallel is not really Prism specific. Nearly any significant language sooner or later had a port or branch that experimented, even Pascal (see vector pascal, a TP dialect based one). So I still don't really have an idea why you would want it, and what you would do with it, except nice goodies as description and probably a liking for method instead of procedure/function. And then I'm not even speaking if it is doable and worth it, and just restricting myself to the WHY? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
On 07/12/2010 02:15 PM, Marco van de Voort wrote: But why? What does it make possible? What would you use it for in practice, that you can't use Prism+mono for? In fact the Prism Compiler is free - but not open source -, but to use the IDE and a component library you even not only need to use payed service by Embarcadero, but also you need to use the Microsoft Visual Studio. I feel that Lazarus as an IDE and component library is more desirable than Visual Studio. AFAIK there is no version of the Prism compiler that runs on Linux or Mac. Moreover I thinks it's viable to prefer open source tools Like what? As said, parallel is not really Prism specific. See Compiler features in e.g. http://prismwiki.codegear.com/en/New_Features http://prismwiki.codegear.com/en/New_Features#August_2009_Release_.283.0.21.29 http://prismwiki.codegear.com/en/New_Features#May_2009_Release_.283.0.19.29 http://prismwiki.codegear.com/en/New_Features#February_2009_Release_.283.0.17.29 http://prismwiki.codegear.com/en/New_Features#November_2008_Release_.283.0.15.29 So I still don't really have an idea why you would want it, and what you would do with it, except nice goodies as description and probably a liking for method instead of procedure/function. In fact I did not test anything of this - and don't have the need to do so - and of course anything can be coded with what we already have. But if we want to go on attracting application programmers we might need to support the C# and .Net - based features that they learned in schools. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
Michael Schnell schrieb: IMHO a lot more interesting than ISO-Pascal, Modula, Oberon: What about Delphi-Prism on that behalf. ? (This supposedly would be easier to make working using a .NET/MONO-code generating backend compiler than by attempting to reproduce the appropriate functionality as far as viable such as parallel in the RTL.) Feel free to implement a Pascal front-end for Mono :-) But what development language would you use for that project? Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility (uses). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] snapshot problems - solved?
Snapshots were broken. Think this is now fixed. The v2.5.1 and v2.4.3 snapshots for go32v2 and win32 should now be updated more or less daily again in /v25 and /v24 respectively, on the fpc ftp sites /pub/fpc/snapshot/. Regards John Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu schützen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] arm embedded cortexM3 unrecognized opcode
I wrote a procedure to turn on interrupts:- procedure intenable;nostackframe; begin asm cpsie i end; end; The compilation fails with 'Error: Unrecognized opcode cpsie' The compiler also does not recognise 'cpsid' and also 'primask' as in 'mrs r0,primask' any ideas/workarounds? Geoffrey ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Michael Schnell schrieb: I just stripped down the machine files for a no_cpu machine (all fakes), with some documentation about the required units etc. Is this based on what we already have for X86, ARM, etc, or does it fork to another set of ARC implementations ? If fork, is it intended / viable to move the existing implementations into that scheme ? The no_cpu skeleton was stripped down from the M68K machine, which in turn seems to have inherited from the ARM. Due to hard coded dependencies it was impossible to remove e.g. registers completely, and also a $define of some already known machine must be given, else every compilation will fail immediately with an $fatal error. That skeleton reflects the units, data structures and procedures, that are referenced by other parts of the compiler (hard coded). Every machine consists of a formal description (registers, instructions...), node generators for the parse tree, code (tree) optimizers, assembler and output generators for binary code and debug info. A distinct machine back-end is selected by adding its source folder to the unit search path. This may be the fastest possible implementation for one (of multiple) machines, but it doesn't allow to support multiple machine back-ends in one program. The same applies to the front-ends, which currently are not exchangable at all. More flexibility would require a plug-in scheme or similar, hard to do without dynamically loadable packages. But since some abstract links already exist (class type variables for machine specific descendants), these links could be exchanged at runtime, not only in the initialization section of the machine specific units. Then it would be sufficient to add all (wanted) front- or back-ends to the compiler, and switch amongst these at runtime. Where switching the target machine at runtime does not make much sense to me, in contrast to switching front-ends based on the source file types. An implementation of a new CPU, based on that skeleton, would rise the priority for further explorations and documentation. No idea in what state the structure / documentation of the existing fully supported implementations such as x86 and ARM is. I could not find much, and most existing documentation is outdated since 2.0 :-( Some parts, like the parse tree nodes, are somewhat self-explaining. The formal machine descriptions (registers, options...) are almost undocumented. I tried to make the construction of the register descriptor constants more transparent, by composing them from other sets of constants. There seem to exist tools that produce e.g. register descriptors (in include files), but I did not yet dig into the tools folder. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
Michael Schnell schrieb: I feel that Lazarus as an IDE and component library is more desirable than Visual Studio. AFAIK there is no version of the Prism compiler that runs on Linux or Mac. A platform independent solution would implement the IDE, compiler etc. in .NET/Mono, so that it can be used immediately on every platform, that supports .NET. AFAIK Java development systems went the same way... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Michael Van Canneyt schrieb: The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible. Bottom line is: don't use 'in' for the uses clause; use the command-line option to specify the location of the sources. Then we could start by immediately flagging all uses of in as deprecated, unless e.g. TP7 or Delphi mode is selected. When the users can demonstrate that they still need such a feature, we could think again about other (more compatible) solutions for not yet covered special cases, before dropping it from the FPC syntax. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
Michael Schnell schrieb: If you want paralel, take vector pascal, and implement it in e.g. the FPC or objfpc dialect. I suppose this is a good idea, even tough I suppose that the .Net parallel paradigm is a lot more broadly known than that of Vector Pascal. so Hans-Peter might want to add VP to his list. It won't find its way into my primary list, because it requires according updates of the internal compiler data structures, RTL and more. We'll need a team of experts that works together on the definition and implementation of all the new features, in all affected parts of the compiler. Some refactoring of the existing compiler infrastructure may be required before this step, so that the further development can stay synchronized with the mainstream development and fixes. The syntax/semantics separation is a step towards this goal, that can be followed by another generalization of the semantical actions. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Hans-Peter Diettrich schrieb: But since some abstract links already exist (class type variables for machine specific descendants), these links could be exchanged at runtime, One problem are all the used constants describing the target architecture. We discussed multiple back-ends in one compiler already in 2002 and saw no advantage in it so we didn't try to solve it and we decided to use the fpc -P ... solution which makes no difference for the user. For me, a much higher priority when doing rewrites might be multithreading nf the compiler itself. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[OT] .NET vs. Java backend (was: Re: [fpc-devel] FPC Branches)
Hi! On 12.07.2010 11:59, Hans-Peter Diettrich wrote: Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility (uses). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-( Sorry for the OT, but why do you believe that a .NET backend is less useful than a Java one? Both environments have a stack based intermediate language (.NET: CLR Java: Bytecode) and a class system resolving around a base object class type. Both use the concept of namespaces to identify classes (the .NET one is solely file name based while the Java one is directory and file based). Also the CLR is standardized while the Bytecode is not. I personally don't think that neither one is really better, but I myself prefer .NET cause it was designed to be used by multiple languages (e.g. C#, Delphi Prism, F#, IronPython, etc). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [OT] .NET vs. Java backend (was: Re: [fpc-devel] FPC Branches)
Java tries to be write once, run everywhere, while .NET is more like write in any language, as long as you run it at our operating system. Forget Mono, it's doomed to always play catch with Microsoft's implementation due to technical and legal issues. 2010/7/12 Sven Barth pascaldra...@googlemail.com Hi! On 12.07.2010 11:59, Hans-Peter Diettrich wrote: Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility (uses). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-( Sorry for the OT, but why do you believe that a .NET backend is less useful than a Java one? Both environments have a stack based intermediate language (.NET: CLR Java: Bytecode) and a class system resolving around a base object class type. Both use the concept of namespaces to identify classes (the .NET one is solely file name based while the Java one is directory and file based). Also the CLR is standardized while the Bytecode is not. I personally don't think that neither one is really better, but I myself prefer .NET cause it was designed to be used by multiple languages (e.g. C#, Delphi Prism, F#, IronPython, etc). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Atenciosamente, Alexsander da Rosa Linux User #113925 Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude. -- Barry Goldwater ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Add the missing instructions to the bottom of armins.dat, run mkarmins in the same directory. (and then submit patch) :-) Geoffrey Barton skrev: I wrote a procedure to turn on interrupts:- procedure intenable;nostackframe; begin asm cpsie i end; end; The compilation fails with 'Error: Unrecognized opcode cpsie' The compiler also does not recognise 'cpsid' and also 'primask' as in 'mrs r0,primask' any ideas/workarounds? Geoffrey ___ 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] Purpose of uses ... in?
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible. Bottom line is: don't use 'in' for the uses clause; use the command-line option to specify the location of the sources. Then we could start by immediately flagging all uses of in as deprecated, unless e.g. TP7 or Delphi mode is selected. When the users can demonstrate that they still need such a feature, we could think again about other (more compatible) solutions for not yet covered special cases, before dropping it from the FPC syntax. I agree. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote: Michael Schnell schrieb: I feel that Lazarus as an IDE and component library is more desirable than Visual Studio. AFAIK there is no version of the Prism compiler that runs on Linux or Mac. A platform independent solution would implement the IDE, compiler etc. in .NET/Mono, so that it can be used immediately on every platform, that supports .NET. AFAIK Java development systems went the same way... Huh ? That would be the day ? AFAIK Java doesn't need .NET ? Why would it need .NET ? It's runtime engine works on more platforms than .NET/Mono... I would even say more: if Java depended on .NET, why would anyone bother with Java ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
In our previous episode, Hans-Peter Diettrich said: Michael Van Canneyt schrieb: The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible. Bottom line is: don't use 'in' for the uses clause; use the command-line option to specify the location of the sources. Then we could start by immediately flagging all uses of in as deprecated, unless e.g. TP7 or Delphi mode is selected. When the users can demonstrate that they still need such a feature, we could think again about other (more compatible) solutions for not yet covered special cases, before dropping it from the FPC syntax. See http://www.stack.nl/~marcov/porting.pdf paragraph 7 (avoid paths...) I originally wrote that in 2003-2004. Even for portability purposes it often doesn't work, since usually the build systems and files for FPC/Lazarus and Delphi differ anyway (and you noticed the working dir difference) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
In our previous episode, Hans-Peter Diettrich said: Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility (uses). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-( Not frontend, not backend, and not most of the libs indeed. I think it would be more logical to add a Prism frontend to Mono. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
Marco van de Voort escreveu: In our previous episode, Hans-Peter Diettrich said: Honestly, a .NET back-end is less useful than e.g. a Java back-end, and requires much work in the front-end for assembly compatibility (uses). Next a new debugger-interface is needed, and a VCL.NET. All in all a very new project, that can inherit almost nothing from the current FPC :-( Not frontend, not backend, and not most of the libs indeed. I think it would be more logical to add a Prism frontend to Mono. They are already doing that: http://blogs.remobjects.com/blogs/mh/2010/05/23/p1504 Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Marco van de Voort wrote on Mon, 12 Jul 2010: In our previous episode, Hans-Peter Diettrich said: Michael Van Canneyt schrieb: The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible. Bottom line is: don't use 'in' for the uses clause; use the command-line option to specify the location of the sources. Then we could start by immediately flagging all uses of in as deprecated, unless e.g. TP7 or Delphi mode is selected. When the users can demonstrate that they still need such a feature, we could think again about other (more compatible) solutions for not yet covered special cases, before dropping it from the FPC syntax. See http://www.stack.nl/~marcov/porting.pdf paragraph 7 (avoid paths...) I originally wrote that in 2003-2004. Even for portability purposes it often doesn't work, since usually the build systems and files for FPC/Lazarus and Delphi differ anyway (and you noticed the working dir difference) The working dir difference is a Lazarus difference, not an FPC difference. Afaict, that feature works identically in FPC and in Delphi. Furthermore, at least two of the users have already posted in this thread saying that they use this functionality (both in FPC and in Delphi). Therefore I don't think it is a good idea to remove or change it. If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [OT] .NET vs. Java backend (was: Re: [fpc-devel] FPC Branches)
Alexsander Rosa wrote on Mon, 12 Jul 2010: Java tries to be write once, run everywhere, while .NET is more like write in any language, as long as you run it at our operating system. Forget Mono, it's doomed to always play catch with Microsoft's implementation due to technical and legal issues. There are two levels of .NET: on the one hand you have the bytecode format (CIL = Common Interface Language), and on the other hand you have runtime and its frameworks frameworks (CLI = Common Language Infrastructure). A .NET backend would mean generating CIL bytecode as far as the compiler is concerned. Conceptually, this would be not very different to generating, e.g., LLVM byte code. It's just an intermediate format that can be fed into other tools and either be used in a JIT environment, or be statically compiled down to machine code (there is e.g. a GCC frontend that reads CIL, and subsequently can in principle generate machine code for any architecture supported by GCC -- but before anyone gets any dreams: this would still also require at least some rudimentary support for that architecture in FPC). The advantage of generating such an intermediate format is that it lets you take advantage of many tools that have been written by other people if you wish to do so. Supporting the CLI (like Delpi.NET/Delphi Prism) would additionally require adding support for an extra operating system to the compiler and the RTL, namely the CLI platform. It's this latter part where Mono is indeed generally about one generation behind the latest Microsoft version. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Florian Klaempfl schrieb: Hans-Peter Diettrich schrieb: But since some abstract links already exist (class type variables for machine specific descendants), these links could be exchanged at runtime, One problem are all the used constants describing the target architecture. We discussed multiple back-ends in one compiler already in 2002 and saw no advantage in it so we didn't try to solve it and we decided to use the fpc -P ... solution which makes no difference for the user. Full ACK. For me, a much higher priority when doing rewrites might be multithreading nf the compiler itself. That's questionable, depending on the real bottlenecks in compiler operation. I suspect that disk I/O is the narrowest bottleneck, that can not be widened by parallel processing. It also requires further research, for e.g. the determination of the optimal number of threads, depending on the currently available resources on a concrete machine. But of course it's worth a try, to find out more... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Branches
Michael Van Canneyt schrieb: A platform independent solution would implement the IDE, compiler etc. in .NET/Mono, so that it can be used immediately on every platform, that supports .NET. AFAIK Java development systems went the same way... Huh ? That would be the day ? AFAIK Java doesn't need .NET ? A .NET development system is typically built on top of .NET, a Java development system on top of Java. FPC instead is not built on top of a single system, and supports more than a single target. That makes it different from beforementioned development systems. The Delphi maintainers decided to restrict the development system to Windows, but plan to allow for multiple targets by cross-compilation (and remote debugging?) features (Delphi X). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Jonas Maebe schrieb: Furthermore, at least two of the users have already posted in this thread saying that they use this functionality (both in FPC and in Delphi). Therefore I don't think it is a good idea to remove or change it. ACK. My concern is about new users with (possibly) new uses of that construct, that will not work with the current implementation. We should cleary state that the use of the in feature is not recommended in new projects, and its use may lead to unexpected results. If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning. I don't think that unit aliasing requires a new construct. In technical terms it only affects the (one-time) comparison of the file and unit name. It *may* have more consequences, like the determination of the source file (name) from a unit name in an IDE, but I don't think that the required changes (if ever) would exceed similar comparisons. But all such considerations can be postponed, till a real and broad need for such a feature exists, or until a user comes up with an according patch. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Purpose of uses ... in?
Marco van de Voort wrote on Mon, 12 Jul 2010: In our previous episode, Hans-Peter Diettrich said: Then we could start by immediately flagging all uses of in as deprecated, unless e.g. TP7 or Delphi mode is selected. When the users can demonstrate that they still need such a feature, we could think again about other (more compatible) solutions for not yet covered special cases, before dropping it from the FPC syntax. See http://www.stack.nl/~marcov/porting.pdf paragraph 7 (avoid paths...) I originally wrote that in 2003-2004. Even for portability purposes it often doesn't work, since usually the build systems and files for FPC/Lazarus and Delphi differ anyway (and you noticed the working dir difference) The working dir difference is a Lazarus difference, not an FPC difference. Afaict, that feature works identically in FPC and in Delphi. Furthermore, at least two of the users have already posted in this thread saying that they use this functionality (both in FPC and in Delphi). Therefore I don't think it is a good idea to remove or change it. If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning. When checking, I found that it is used for all files in UltraStar Deluxe. I was not aware that this part of the code is problematic also have no idea about the actual reason. Maybe relates to compiling with Delphi. In any case I would definitely hate to have the code broken. Nevertheless, I will raise the topic. P.S. This will probably end up in the wrong thread, because I answer to the dictionary. At least it did in the past. Any hints? Michael___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
