[fpc-pascal] target mipsel-embedded
I am trying to build a mipsel-embedded compiler. It says here that this is possible https://wiki.freepascal.org/TARGET_Embedded_Mipsel. I followed the steps below git clone https://github.com/fpc/FPCSource.git cd ./FPCSource make clean buildbase installbase INSTALL_PREFIX=$HOME/mips/fpc-mipsel CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=mipsel SUBARCH=pic32mx BINUTILSPREFIX=pic32- And got messages make[3]: *** No rule to make target 'mipsel/startup.s', needed by 'startup.o'. Stop. Indeed, the source codes do not contain the directory rtl/embedded/mipsel And there is no sturtup.s file. And the modules pic32mx1xxfxxxb pic32mx2xxfxxxb pic32mx1xxfxxxc pic32mx2xxfxxxc pic32mx1xxfxxxd pic32mx2xxfxxxd pic32mx7x5fxxxl pic32mx7x5fxxx referenced by makefile.fps is also not present. Although for other platforms are available. chipKIT-cxx is installed, version 1.43 (GCC-4.8.3 binutils 2.23.51). Links in the wiki are no longer working, but there are no earlier versions in the github. Somehow they built it. Help me figure it out, please. Thanks. -- Sergey __ Получить адрес @meta.ua http://webmail.meta.ua/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 28, 2021, at 7:01 PM, Sven Barth wrote: > > Anything that relates to picking functions *must* be part of the overload > handling. You can easily see this with your named argument proposal when not > all arguments are named (and then the compiler also needs to check that > unnamed parameters aren't used for named ones as well, this gets more > complicated if the overloads have different argument names). > > You should have already learned this lesson when I pointed you in the right > direction for the implicit function specializations. > I'm not proposing we necessarily allow the reordering of arguments or allow omitting of values. In the simplest scenario they're just optional names but the parameters still need to be provided in the correct order. Very simply to make reading long functions easier at the call site. Yes I understand that the overloading happens after parsing. In your first example if arbitrary order was allowed new overloading rules would need to be applied so that you got an ambiguous function error. Not a big deal to resolve that I would think but it doesn't have to go in that direction either. Personally I'm not in favor or changing the overloading rules, just that some calls were easier to read by glancing over them. In fact I have seen IDEs which have a feature which inserts the param name into the editor for this very reason. As an aside, is it even useful to allow arbitrary parameter order? I don't recall ever wanting this and would open the door to some functions being called in different order across a codebase, which sounds like a big problem unto itself (C# allows this btw). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Ryan Joseph via fpc-pascal schrieb am So., 28. Nov. 2021, 03:12: > > > > On Nov 27, 2021, at 5:00 PM, Sven Barth > wrote: > > > > The compiler does not know which routine is called upon parsing the > parameter declarations (which would mean that error reports would need to > be deferred until the lookup of the routine failed). > > My idea was to not actually have it affect overloading except in the case > where the param names don't match which would ignore the call (so in your > example below nothing changes). > > Otherwise if the name was actually part of the overloading we would have > to allow functions with the same parameter type but different names, i.e.: > > procedure Foo(Arg1: String = ''); > procedure Foo(Arg2: String = ''); > > and that would be a big change to the language and have all sorts of > implications. > > So it's really just a minor hint to make the call more readable in the > case of long function names. > Anything that relates to picking functions *must* be part of the overload handling. You can easily see this with your named argument proposal when not all arguments are named (and then the compiler also needs to check that unnamed parameters aren't used for named ones as well, this gets more complicated if the overloads have different argument names). You should have already learned this lesson when I pointed you in the right direction for the implicit function specializations. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
Ryan Joseph via fpc-pascal schrieb am So., 28. Nov. 2021, 05:32: > > > > On Nov 27, 2021, at 5:03 PM, Sven Barth > wrote: > > > > candidates:=tcallcandidates.create(sym:=symtableprocentry, > st:=symtableproc,ppn:=left, > ignorevisibility:=ignorevisibility,allowdefaultparas:=not(nf_isproperty in > flags),objcidcall:=cnf_objc_id_call in > callnodeflags,explicitunit:=cnf_unit_specified in > callnodeflags,searchhelpers:=callnodeflags*[cnf_anon_inherited,cnf_inherited]=[], > anoninherited:=cnf_anon_inherited in > callnodeflags,spezcontext:=spezcontext); > > > > So you've gained *nothing*. > > I wouldn't say nothing but it's still really hard to read. My only thought > there was that it would open the door for some syntax coloring on the > parameter name so you can scan them easier. > Lazarus already highlights commas differently, so one can easily differentiate the parameters. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
> On Nov 28, 2021, at 4:18 PM, Mattias Gaertner via fpc-pascal > wrote: > > What do you mean? Is there already some call by arg names in some > mode(switch)? I mean all the plumbing is there so the feature could easily be extended from IDispatch to work with normal function calls. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
On 28/11/2021 10:18, Mattias Gaertner via fpc-pascal wrote: On 26.11.21 04:10, Ryan Joseph via fpc-pascal wrote: [...]The majority of the infrastructure is already there so it needs to merely be extended. What do you mean? Is there already some call by arg names in some mode(switch)? No, it's only there for IDispatch support: https://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Named optional arguments
On 26.11.21 04:10, Ryan Joseph via fpc-pascal wrote: [...]The majority of the infrastructure is already there so it needs to merely be extended. What do you mean? Is there already some call by arg names in some mode(switch)? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
