ValKmjolnir / Nasal-Interpreter

Modern efficient runtime for Nasal: using stack-based direct-threading virtual machine.
https://www.fgprc.org.cn/nasal_interpreter.html
GNU General Public License v2.0
54 stars 4 forks source link

cross-platform #10

Closed limuy2022 closed 1 year ago

limuy2022 commented 2 years ago

Could you use cmake instead of make, otherwise I can't compile it on Windows. If you agree, I will make a pull request later(maybe next week) to solve this problem

ValKmjolnir commented 2 years ago

In fact now i don't really want to use Cmake to compile this simple project. We've tested that this project can be compiled successfully on Windows 10 with MinGW-w64.

And we've written in README.md that Windows platform should use MinGW-w64 to compile this. If you have any problems compiling the interpreter using MinGW-w64, please write the problem here and we will help you to find the solution.

That's the answer. But you could also make this pull request and we could see if it really helps more other users compiling the project without MinGW-w64 on Windows(etc MSVC, VS). Thank you very much for supporting us!

limuy2022 commented 2 years ago

Mingw is very uncommon on Windows.So I want to make it work widely on windows. ......In fact,I tried using cmake in your project.But it used a lot of functions and header files that is only for linux.Making it can be compiled on the msvc or clang is very difficult

ValKmjolnir commented 2 years ago

Aha, maybe you will find MSVC cannot compile this even if you use CMake. I don't know if MSVC now can use the gcc-extension Labels as Values(clang can do this). I use MinGW-w64 all the time and DON'T like MSVC. And you must know that MinGW is not UNCOMMON like you said.

But this is a public project, so this is necessary to support MSVC/VS users to compile it. It is worthwhile to make this effort. Though my team members all don't like MSVC/VS lol :).

To make this project available on MSVC/VS is not just writing a correct CMakeLists.txt. As you said, MinGW using many headers and functions that designed for unix/linux platform. Also MinGW make these functions running on Windows too. So it is not like what you said: ONLY for linux. That is not correct. If you want to compile it using MSVC/VS, maybe you should do quite a lot of work, using macros, replacing all the functions MinGW has but MSVC/VS doesn't have with those that MSVC/VS has. It is not that easy, but if you have any problems, contact us and we could find the solutions together.

sidi762 commented 2 years ago

I agree with Valk that MinGW should be sufficient for windows support. While adding support for MSVC could be helpful for windows users, this shouldn't be the majority goal for this project. It would still be great if limuy2022 could manage to add MSVC and cmake support for this project though.

Kind regards, Sidi

limuy2022 commented 2 years ago

ok,I will try to make it work

ValKmjolnir commented 1 year ago

Seems that you've encountered great critical problems that there are too many errors that VS generated. After thinking for such a long time. We decide to try to make it compilable with MSVC, though there may be loss of performance. After finishing this work, we will close this issue.

limuy2022 commented 1 year ago

In fact, I'm a 14-year-old junior high school student, and I don't think porting code to MSVC is very difficult and has no impact on performance.I think this even improves it. But I recently had an important competition (The Informatics Olympiad), so I have been training almost every day recently, which took me almost a day, so I didn't have much time to try to port this project.

ValKmjolnir commented 1 year ago

I choose indirect-threading instead of labels as values to make sure MSVC could compile it. And all the functions that MSVC doesn't support have been replaced. Now the interpreter itself can be compiled in Visual Studio. And we will fix some bugs in nasal_builtin.h. Thank you for your suggestion and wish you a good luck competing OI.

ValKmjolnir commented 1 year ago

I choose indirect-threading instead of labels as values to make sure MSVC could compile it. And all the functions that MSVC doesn't support have been replaced. Now the interpreter itself can be compiled in Visual Studio. And we will fix some bugs in nasal_builtin.h. Thank you for your suggestion and wish you a good luck competing OI.

And after testing compiling this project through gcc, clang, MSVC, he test file test/ycombinator.nas shows that: MSVC: 1.17s MinGW-g++: 0.71s LLVM-clang++: 0.56s If MSVC could compile labels as values, the performance should be equal to g++ and clang++. But that's not very important now. We will do some optimization later to help it running faster. 😄

limuy2022 commented 1 year ago

Labels as values is not a standard C++ definition .We should remove it.Wish your project will be nicer and faster!

ValKmjolnir commented 1 year ago

Labels as values is not a standard C++ definition .We should remove it.Wish your project will be nicer and faster!

That's your own choice. We prefer GCC/Clang. 😅