Re: [MSEide-MSEgui-talk] Status of MSELang
Hello. There are some test-benchmark of mselang here: https://github.com/mse-org/mselang/tree/master/src/benchmark -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On 19/04/2021 6:32 am, Alexander via mseide-msegui-talk wrote: > And why do you need LLVM when using Pascal? How about .pas to ELF directly ? >From what I understand, LLVM does very very impressive optimisations when in generates the final binary executable. Way more that what the FPC compiler can achieve. Even Delphi's compiler does a LOT more optimisations that FPC - hence Delphi binaries tend to be a lot faster. The Kylix compiler was the same. Martin used to often post speed comparisons in the FPC mailing list to show how slow FPC was. It is well known that the Free Pascal developers pay more attention to the FPC code being maintainable and supports easier porting to new platforms or CPU's - than they do about optimising the final binary. With MSELang, you will still program in "object pascal", it will just be using LLVM that generates the final optimised binary. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
> And why do you need LLVM when using Pascal? Because LLVM does it much better for float calculation for example. "Pure" fpc is ok for database applications for example but once you work with animation, DSP, live sound effect, etc, where lot of float calculation is needed, the result is much slower than using LLVM. In my side, I am more interested with sound applications and multi-media, and a fpc application cannot be fast as LLVM. But, at the moment, LLVM has only a C module and I will be very happy if there is a Pascal LLVM module, like mselang. > How about .pas to ELF directly ? Maybe but the problem will be the same as using fpc, how will you do for the optimization that LLVM does? Note that even Google has choose LLVM for his applications now and will contribute to make LLVM better. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On Sun, 18 Apr 2021 05:19:33 -0700 (MST) fredvs wrote: > FPC, in trunk, can produces Assembler code that can be used by a > interpreter. > But this is not "pure" LLVM Bitcode File (.bc) and, it seems that fpc has no > plan to do it. And why do you need LLVM when using Pascal? How about .pas to ELF directly ? ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
Hello Alexander. > Martin did not have time to fully connect MSE and MSElang. Indeed it was just in plan to do the junction with MSElang and MSEguI. His plan was to have something working before the end of 2018. By the way, if the project mselang continue, imho, it would be easier to first make work fpGUI. -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
> I remember that Martin seemed enthusiastic about the progress of MSElang, so > I think this is a project that would be really worth continuing. The skill of Martin is the highest that I met. He is the only one in the world that was able to create a compiler who produces LLVM Bitcode File Format (other than clang and other C bitcode compilers). FPC, in trunk, can produces Assembler code that can be used by a interpreter. But this is not "pure" LLVM Bitcode File (.bc) and, it seems that fpc has no plan to do it. Imho, mselang is the brightest pearl for Pascal language and the only hope to have a Pascal LLVM compiler. To arrive at the same level as mselang is now, with full-time skilled programmers, no chance to have something working before minimum 10 years (if they begin now). Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
@Graeme Glad that you feel interested in MSElang. I am like Fred: I wouldn't be able to continue the project, but if I can help I will do with great pleasure. I have just installed Clang to start experimenting. I remember that Martin seemed enthusiastic about the progress of MSElang, so I think this is a project that would be really worth continuing. Regards. Roland -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On Sat, 17 Apr 2021 17:16:13 +0100 Graeme Geldenhuys wrote: > Hi, > > 1. Anybody know what the status is of MSELang? Apparently frozen. > 2. How far did Martin get with it > 3. Anybody else working on it now? Not. I do not use it. But I save it. Martin did not have time to fully connect MSE and MSElang. > > > Regards, > Graeme ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
> If you really want to keep this alive, try finding some computer science > university students with an interest in compiler writing. Hello. I did present mselang to LLVM mailing-list: http://clang-developers.42468.n3.nabble.com/Clang-Windows-and-stdout-td4063613.html And also on a LLVM forum, presenting a mselang, the brother of clang but for Pascal language. There was lot of enthusiasm, that it would be great to have a bitcode Pascal compiler in the LLVM family. But after this, no more sound. Yes, maybe in university but I dont have the skill to answer to questions about LLVM and the bc files compiled by mselang. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On 4/17/21 12:34 PM, fredvs wrote: Hello Graeme. 1. Anybody know what the status is of MSELang? There was some work done to make it work: https://github.com/mse-org/mselang/releases I was able to do some console application on Linux (the version of LLVM for Windows was not yet working when I try it 3 years ago). But I dont have the skill to continue the work. 2. How far did Martin get with it Imho, all the hard-dirty work was already done. On Linux, Raspberry pi and FreeBSD all is working, MSElang can produce mli, bc and working executable. MLI file are mselang files ready to produce bc files that can produce executable using LLVM. You may try the demo included in https://github.com/fredvs/mselang/releases. Martin was busy with the RTL but only the basis is done. For example, for console app, "writeln()" is working (like charm) but "readln" was not yet implemented. 3. Anybody else working on it now? Afaik, not a lot, but It would be great if somebody jump into it, I will encourage and follow him a lot. Fre;D If you really want to keep this alive, try finding some computer science university students with an interest in compiler writing. They would be the best bet to take mselang forward imho. Patrick ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
> Umm, this sounds very interesting. I'll definitely take a look around > MSELang and try it out. If you like FreeBSD (that "is" LLVM and uses only clang now), once you have a working bc LLVM bitcode file, you are the king. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On 17/04/2021 6:08 pm, fredvs wrote: > That said, once the mli and bc file is produced, no matter if it was > produced by a 32 bit compiler, running LLVM you may choose the target you > want, 32 or 64 bit. Umm, this sounds very interesting. I'll definitely take a look around MSELang and try it out. Regards, Graeme ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On 17/04/2021 5:34 pm, fredvs wrote:
> There was some work done to make it work:
> https://github.com/mse-org/mselang/releases
>
> I was able to do some console application on Linux (the version of LLVM for
> Windows was not yet working when I try it 3 years ago).
Thank you Fred for all the information. I'm looking at the MSELang repo
as we speak.
The reason I ask, I was comparing Delphi's Anonymous Methods (lambdas) +
Generics
to how Java does it. It is crazy how verbose Embarcadeco made the syntax. The
compiler
is supposed to be inteligent, yet with the Delphi syntax, you are spoon-feeding
the compiler with things it could have figured out from the code itself, and
often
duplicating information. You really don't save much typing that way.
I'm toying with the idea of experimenting with the Free Pascal Compiler, and
was looking at maybe contributing to FPC (if they don't want it - most
likely outcome - as they only like to copy Embarcadero), then the other option
might be MSELang. But I don't know anything about MSELang and what its
goals were. But I've got a better idea now - thanks to all your links.
The rest of this message is optional... ;-)
Here is a simple example:
[ As done in Delphi ]
type
TSimpleProcedure = reference to procedure;
TSimpleFunction = reference to function(x: string): Integer;
var
x1: TSimpleProcedure;
y1: TSimpleFunction;
begin
x1 := procedure
begin
Writeln('Hello World');
end;
x1; //invoke anonymous method just defined
y1 := function(x: string): Integer
begin
Result := Length(x);
end;
Writeln(y1('bar'));
end.
==[ end Delphi ]=
Now for my idea...
There are some standard "functional interfaces" defined in the RTL like,
but in your own code, you can define your own ones too. The compile will
treat them in the same way is I describe here:
type
// Represents a function that accepts one argument and produces a result.
IFunction = interface
function apply(T): R;
end;
// Represents a predicate (boolean-valued function) of one argument.
IPredicate = interface
function test(T): boolean;
end;
// Represents an operation that accepts a single input argument and returns
no result.
IConsumer = interface
procedure accept(T);
end;
// Represents a supplier of results.
ISupplier = interface
function get: T;
end;
// Represents a prodecute that takes no argument and produces no result.
IRunnable = interface
procedure run;
end;
You can then use those in anonymous methods like this:
[ Mine ]===
var
x1: IRunnable;
y1: IFunction;
begin
x1 := () -> Writeln('Hello World'); (1)
x1; //invoke anonymous method just defined
y1 := s -> Result := Length(s); (2)
Writeln(y1('bar'));
end.
==[ end Mine ]=
(1) - The () syntax lists any parameters. It's empty, so no parameters
are used. They are only required if the parameter list is empty.
- The -> syntax borrows from Java and lets the compiler know this
is a lambda (anonymous method)
- IRunnable's method takes no parameters and has no return type
- The code after the -> is the body of the method. This is a 1 line
body, so doesn't require the verbose begin/end pair.
IRunnable is a "functional inteface" with only one method that needs
to be implemented. From that the compiler knows the name and signature
of the method, by looking it up from the interface definition. The
compiler can construct a anonymous class to implement the anonymous
method. That could automatically result in something like this - all
done by the compiler itself:
type
TInternalAnonymousClassName = class(TInterfaceObject) implements IRunnable
public
function run;
end;
TInternalAnonymousClassName.run;
begin
Writeln('Hello World');
end;
(2) - The process is pretty much the same as (1), but this time the
functional inteface signater is different.
- IFunction takes one parameter and returns a result.
- The definition of y1 tells the compiler that the parameter
is of type String and the return type is of type Integer.
So when you define the lambda, you don't have to repeat the
data type information
- s is the name of the parameter, and the compiler already knows
is must be of type String.
- agian it's a one line method, so no need for the begin/end pair.
type
TInternalAnonymousClassName = class(TInterfaceObject) implements IFunction
public
procedure apply(s: String): Integer;
end;
TInternalAnonymousClassName.apply(s: String): Integer;
begin
Result := Length(s);
end;
Regards,
Graeme
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
> 2. How far did Martin get with it The last commit of MSElang date of Nov 28, 2018 11:05am https://gitlab.com/mseide-msegui/mselang/-/commit/353afb4f8d3d7cc9b1af35f0a417bb25ec53a4a6 And Martin leave us the November 29, 2018. ;-( Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
Re hello Graeme. Note that there is only working releases 32 bit (including FreeBSD). Martin did not yet make a 64 bit version of MSElang. I did try to make a 64 bit version but I was stopped about class conversion to 64 bit (no skill enough). That said, once the mli and bc file is produced, no matter if it was produced by a 32 bit compiler, running LLVM you may choose the target you want, 32 or 64 bit. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
> And lastly, what was the actual goal of MSELang? Was it to introduce a > more modern "Object Pascal" like syntax, or only to use LLVM as the > code generator (thus more optimised code or more platforms)? Or a > combination or these? >From what I understood, the goal is to keep the "Object Pascal" syntax of Delphi 7 to produce LLVM Bitcode File Format. With that bc file, you may produce executable for each target you want. Here from the rmselang eadme.txt: --- In the beginning of 2013 I decided to make an own compiler for the MSEide+MSEgui project and started to experiment. The reason is the development direction of Delphi since Delphi 7 which makes it less suitable for my tasks and knowing that Free Pascal is closely following the same direction. The design goals Ultimate goal is to build the most productive universal programming environment, usable from programming of microcontrollers to MSEgui projects. 1. Simple. Reduce the language concepts one has to learn to the minimum, make them as orthogonal as possible. 2. Readable. MSElang programs should read like a letter. 3. Easy to learn. Because of 1. and 2. it should be suitable for pupils as first programming language. 4. Powerful Allow to go down to the bare metal, it has pointers and pointer arithmetic. ;-) Object orientated high level programming. 5. Fast running State of the art optimizations. 6. Fast compiling While defining the language keep in mind how it can be implemented efficiently. -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
Hello Graeme. > 1. Anybody know what the status is of MSELang? There was some work done to make it work: https://github.com/mse-org/mselang/releases I was able to do some console application on Linux (the version of LLVM for Windows was not yet working when I try it 3 years ago). But I dont have the skill to continue the work. > 2. How far did Martin get with it Imho, all the hard-dirty work was already done. On Linux, Raspberry pi and FreeBSD all is working, MSElang can produce mli, bc and working executable. MLI file are mselang files ready to produce bc files that can produce executable using LLVM. You may try the demo included in https://github.com/fredvs/mselang/releases. Martin was busy with the RTL but only the basis is done. For example, for console app, "writeln()" is working (like charm) but "readln" was not yet implemented. > 3. Anybody else working on it now? Afaik, not a lot, but It would be great if somebody jump into it, I will encourage and follow him a lot. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Status of MSELang
On 17/04/2021 5:16 pm, Graeme Geldenhuys wrote: > 1. Anybody know what the status is of MSELang? > 2. How far did Martin get with it > 3. Anybody else working on it now? > And lastly, what was the actual goal of MSELang? Was it to introduce a more modern "Object Pascal" like syntax, or only to use LLVM as the code generator (thus more optimised code or more platforms)? Or a combination or these? Regards, Graeme ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] Status of MSELang
Hi, 1. Anybody know what the status is of MSELang? 2. How far did Martin get with it 3. Anybody else working on it now? Regards, Graeme ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
