Hi Jonas, >> - Complete the LLVM branch of FPC. It looks like Jonas has stopped >> working on it two years ago, which is a pity.
> I didn't stop working on it, but I didn't make real progress anymore > either. So, would you be interested in making progress again? :) > a) exception handling in general: indeed needs DWARF-EH support in the > RTL, and also support for the LLVM exception handling intrinsics in the > code generator. I've worked on and off on this and have some local > patches, but it's not complete So maybe someone else could work on DWARF exceptions, which then would enable you to progress on LLVM? > have been working a bit on it since then). This is not something that > can be changed/fixed in FPC, and is quite different from how FPC's > current code generator works (I don't know how Embarcardero deals with > it in their LLVM-based code generator). Someone could do some reverse engineering to learn more about how they have solved the problem (unlike actually copying code I don't see any legal or ethical problem in learning from reversing). If the lone Embarcardero russian Java-developer-turned-compiler engineer can do it, you guys sure can, too ;) > Additionally, in the current FPC code generator global variables behave > mostly as volatile variables. With LLVM, that won't be the case (unless > we mark all of their accesses as volatile, but that would obviously > inhibit LLVM optimizations). This may break some multithreaded code that > currently works, and would probably require the introduction of a > volatile() operatator (similar to the unaligned() one). On the other > hand, I already added support for tracking the volatile state of > references in the past, so that should be easy to do. I have to admit my knowledge on this is very limited. We do use global variables unsynchronized in Multi-Threaded code, but only in a single-writer multiple-reader scenarios, in these cases we don't have any expectations for the new value to be available "immediately". Obviously the compiler can not know at what point during runtime the thread gets scheduled, but what are the rules (if any) on "how long" it takes for a volatile variables content to get "flushed"? Is there some scoping involved like "on return of current function/method"? Unlike the crap that Embarcadero has been polluting the language with in recent years, I think that adding support for volatile() to the language would make a lot of sense - however potentially turning this around so that the unmodified default stays volatile, and an implementing an erm.. "non-volatile" modifier instead, so not to break existing code. Cheers, Simon _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel