How to port to new platforms about chrysalisp HOT 91 CLOSED

Hi Martyn, I was thinking this might be worth doing !

I'd certainly encourage you if you are interested, would be great the have other people having been through the process. First I think a few questions need answering about the strategy for a Windows port.

1. Would it use a layer like the Subsystem for Linux ? Win 10 only ?

2. Are there any special reserved registers that are critical to making windows OS calls or calls to SDL on Windows ? The biggest concern here is if there are any registers that must be reserved in order to allow task switching at the Windows thread level, like a reserved task frame register in r15 etc.

3. What is the ABI for Windows calls, register layout and stack frames.

I can detail the areas in the source that are affected by a port, but let's start with answers to these fundamentals.

Regards

Chris

from chrysalisp.

You will notice on my last push, I have done a long standing change to make the SDL calls the GUI uses just part of the C platforms host interface.

This is something I've been meaning to do for a while. I think all/any host system calls should go via the C function table in the main.c bootstrap rather than direct to the host OS int calls. This should simplify porting to a new host OS greatly.

All the current none SDL sys/pii methods should now be converted to use the hosted C function table. The idea here is to make the host interface only dependent on the platform C compiler and the platform C ABI.

So first steps towards a cleaner interface for your Windows port. !

from chrysalisp.

Also, by using the C++ version of the Lisp we can compile a kernel image without having a runable ChrysaLisp first. Provided the host C++ is available we can compile ChrysaLisp- and use it to build our image while we get things up and running.

https://github.com/vygr/ChrysaLisp-

Chris

from chrysalisp.

Just merged in a big set of changes to make all host platform calls go via the main.c bootstrap.

So your mission, should you accept it, would be to get this to boot on Windows :)

I would suggest first of all, thinking about how to get the launch scripts to work as batch files, think about the build/make for Windows, and set about creating the Windows versions of the main.c bootstrap. Most of the calls there should be fairly easy to emulate on Windows, but there is scope to change things to make things like mmap more abstract if it helps. there's no reason to stick with exposing the raw mmap/munmap/open/unlink calls etc (and it might be better to not do so).

I'll set up the Windows ABI parts in the sys/pii/ files for you based on online documentation, but you might need to double check that as I'll be doing it blind.

Regards to all and happy Xmas.

Chris

from chrysalisp.

Hey Chris,
Thanks very much for all your hard work on this. I have been offline over xmas but am staring to ramp up again. I'll keep you posted on progress!

Thanks,
Martyn

from chrysalisp.

Small progress update. Written code to load the boot image and start executing. With a nop-d version of the host functions I got back a somewhat satisfying 'abort !' message on the console :)

I've now started implementing mmap on (native) windows and seeing calls come in such as:
fd=-1 and len= 0x2000

from chrysalisp.

Lol, I know what you mean about seeing 'abort!' on the console. Like yes, it ran something enough to come back and print an error message ! :)

from chrysalisp.

You can, for now, ignore bringing up the multi-cpu network and link stuff. Just a main.exe that runs a single CPU on it's own will be a great forward leap.

Sounds like the host ABI register stuff for Windows is working as it managed to make the sys/pii/write_str call to do the 'Abort !' from the first heap allocate it tried ! NICE :)

from chrysalisp.

It's getting there. Whats the best way to figure out what the control flow outside of the calls into the host functions are?

from chrysalisp.

(debug-str) and (debug-num) functions. They just use sys/pii/write that you allready have shown works. Find them at the bottom of sys/pii/class.inc

Sorry again for the late reply. I must find out why I not seeing notifications.

Chris

from chrysalisp.

Printf style debugging at it’s finest!

from chrysalisp.

eg:

(debug-str "1")
(debug-str "2")

etc

(assign '(...) '(r0))
(debug-num "value =" r0)

from chrysalisp.

Thanks :) I'll keep you informed!

from chrysalisp.

You do realise that after you've got this working, you will need to write a PORTING.md document ;) As you will be the best person to write one :)

from chrysalisp.

Hmmm, in that case I'll start writing it now :)

from chrysalisp.

Martyn, just pushed a new feature to help you out. I also merged it into the windows branch.

If you look at cmd/asm.inc you will now see a new debug_trace option, normaly 'nil', but if you set it to 't' and recompile everything it will trace out via (debug-str) function entry and exits !!!

I'd advise you to only run a single CPU with this option as the tracing will get mixed up in the console other wise, but your probably doing that anyway at the moment.

Take a look in sys/func.inc at the end of (def-func) to see what the debug_trace flag makes it do. You can tune what functions get targeted for tracing if you want to cut the output down a bit. But leave the guards against statics/vtables/pii functions in there.

Hope this helps your with function tracing needs. Certainly if you getting any crashes you can quickly hunt down the last thing the system was calling before it died ! Then home in via some (debug-str) calls exactly where in that function.

Chris

from chrysalisp.

Hi Martyn,

I was just thinking about the Windows port and wanted to mention something that might not be obvious to somebody doing this for the first time.

All tasks within ChrysaLisp have their own stack area, this is not the same stack area as the original thread that called in from the C bootstrap ! So the only calls back through the C function table that will have that same stack pointer will be from the ChrysaLisp kernel thread, all other threads will NOT have that original stack.

The GUI update process, within ChrysaLisp, asks the kernel thread to do the calls to SDL, as I noticed that not doing so caused crashes on OSX/Linux. I didn't delve far into why that was so, but I guess it's a matter of needing to be able to allocate quite deep structures on the stack or something specific about how a dll needs the original process thread etc.

All the other host calls for things like open, gettime, stat, etc don't do this thread swap to the main thread, it just wasn't required on OSX/Linux as system calls like those use their own stack on the host anyway.

But Windows might not be like that ! And you may find that the Windows host calls needs to be on the original thread that called the boot code ? I don't know if that's the case, but it might be.

Have you experienced any crashes that might be this issue ? If so we can come up with a plan to deal with it.

Regards

Chris

from chrysalisp.

Thanks for this info, I am currently seeing a local stack corruption that only occurs if I call 'boot'. When calling boot, I see some of the entrypoints being called, but im not convinced that my implementation of memmap is correct so it may be due to that. Still doing some debugging:

BTW, I'm currently seeing this when tying to use ChrysLisp- to do a make:
-> obj/Windows/x86_64/class/sequence/vtable
Error: (save str path) open_error ! < ("        ¿ 0 0 h �class/sequence/vtable ��������8 A F M 6 . & class/obj/vtable sys/mem/free class/obj/null class/obj/hash " "obj/Windows/x86_64/class/sequence/vtable") > File: class/sequence/class.vp(4)

its probably something on my side, just thought I would mention it.

from chrysalisp.

I’ll take a look soon as I’m back from the office.

from chrysalisp.

Ah yes. You need to create the obj/Windows/x86_64/class/sequence/ directory ! Or unzip the windows branch snapshot.zip again after a pull. I’d just create the folder.

You should then be fine.

from chrysalisp.

With that folder fix, and the latest Windows branch sources, you should be good to turn on the 'debug_trace t' setting in the cmd/asm.inc file and get function entry/exits out, should give you a much better feel for where it's getting to.

./chrysalisp -b class/lisp/boot.inc cmd/asm.inc
(remake-platforms)

from chrysalisp.

I seem to have taken a step backwards, but in case its useful for you or others, here's where I am.

• I've verified that the memory that I've allocated for the boot_image is correctly setup ( I can fill it with nops's and execute them without incident)
• After the boot image is loaded, the address of the boot function is calculated to be 40 bytes in from the start (of the boot_image file)
• The first instructions thus executed are:
  push rcx
  mov r15, rdx ; (host ptrs)
  push rax
  push rcx
  …
  We then end up jumping to 0000000000029e3a() at which point we fault.

from chrysalisp.

When you say taken a step backwards, what did you do prior to that ? Was it pulling the new stuff ? Enabling tracing?

from chrysalisp.

It's not the tracing. It seems when I added the windows implementation of the memmap. At one point I was seeing the host functions being called, that's no longer happening - so im trying to get back to that. I'm wondering if it could be the boot image somehow - I'm going to rebuild it now and see if that helps

from chrysalisp.

Are you in a position to push the Windows work and I can take a look. I’ve got an old Windows laptop I’ve installed win10 on in case I can assist. Would need to know what tools I should install etc if you want me to try replicate things.

from chrysalisp.

If the first host call was the abort, that was from the first call to memmap that you had returning 0 ?

If you’ve now got it returning a memory address then you will be getting beyond that abort and could be starting to hit another issue.

Are you seeing the Abort again if you switch back to returning 0 ?

from chrysalisp.

The abort message that was coming from Chrysalisp is what Im trying to get back to :( The abort / fault Im seeing now is from jumping to an invalid location ( 0000000000029e3a ) and trying to execute.

from chrysalisp.

I just built the windows branch, and created a windows boot_image. The start of the code is at offset 0x28, and if I dissemble that with an online disassembler I get...

from chrysalisp.

Very cool - thanks this will be a great reference. I went back and built the boot_image from the windows branch and am now seeing the function calls that I expected to see, so back to where I need to be.

from chrysalisp.

I just checked that I get the same result going via building with the C++ Lisp too, it's identical to this.

from chrysalisp.

I wonder if I can drop the boot_image file here, let me try for you...just a zip of the 'boot_image' file I just created.
boot_image.zip

from chrysalisp.

This is the header before the code starts:

FFFFFFFFFFFFFFFF180228001802180200107379732F6C6F61642F696E6974001616161616161616

The sixth short from the from is 0x28, which is the offset to the code start, so that looks ok. Have you accidentally changed the type of the (*boot) to not be a short ? that jump to (boot + boot[5]) is vital that the type of pointer to short else boom !

from chrysalisp.

I'm back to getting the Abort ! message so it was definitely the boot_image that was causing me the problem. I'll reset the code back with real mmap and see where that takes me. Thanks for the help!

from chrysalisp.

Ah, i missed the comment about the rebuild working for you ! :) Good news.

from chrysalisp.

Progress!
".\obj\Windows\x86_64\sys\boot_image" -cpu 0 -run apps/terminal/tui

".\obj\Windows\x86_64\sys\boot_image" -cpu 0 -run gui/gui/gui

from chrysalisp.

Progress indeed ! :)

NICE !

Chris

from chrysalisp.

And lets not forget that single White canvases have sold for millions of dollars in the art world ;)

Chris

from chrysalisp.

bit further...

from chrysalisp.

seeing this error now on the gray grid...

from chrysalisp.

First of all that real good progress !

And a clue here may be that class/lisp/boot.inc (601), that the last line in the file ! So maybe EOF wasn't returned correctly ?

The GUI process that brings up the grey block backdrop isn't a Lisp process, but that runs the first Lisp process which is the 'apps/launcher/app.lisp' and that will be the first to read in the 'class/lisp/boot.inc' file.

The fact we don't see the Launcher app and that we stop at the end of boot.inc all adds up. Plus there is no such thing as 'efmacro', that looks like corruption !

My suspicion would fall on the host read call or the host stat call having returned a wrong size for the boot.inc file, and/or that read gulped into memory a bigger/smaller than actual size chunk.

from chrysalisp.

But this shows that the entire GUI compositor looks to be functioning ! So SDL calls look good and that gives me even more confidence that Windows ABI mapping is working correctly.

Double check the stat code to be sure the file size's are correct. If your sure of that, then check that the read call asking for that size chunk of boot.inc is correct.

from chrysalisp.

Sounds like a plan - thanks for your insight!

from chrysalisp.

TADA!!!!

Boing was bouncing, stopped at this point not sure why but still I'm very happy!

from chrysalisp.

Well done :) Have a drink on me !

Probably worth running with tracing turned on to track that freeze down, but this is great.

Chris

from chrysalisp.

Thanks. I'm off a biz trip tomorrow and wont have this laptop with me, so it will be a week or so before i'm back online. I'll clean up the code and send you a pr.

from chrysalisp.

I'd have a go running just the terminal and trying to do a 'make all', shake any bugs out of the host read/write/stat calls. Should be close to being able to create a build from scratch on the Windows port.

from chrysalisp.

I tried this and not much appeared to happen so I decided to rebuild the boot_image with trailing on. I changed the nil to t and rebuilt. When I ran the boot image I saw the issues where the boot image was corrupted and jumped off into the weeds.

I haven't rebuilt my chrysalisp- in a while so perhaps that's it. I'll try that when I'm back

from chrysalisp.

Have a good trip. Chat when your back.

Chris

from chrysalisp.

Heading back to the UK tomorrow snow storms permitting but it will be Thursday evening until I get access to my laptop again. Wondered if you had any thoughts about the issues that I am seeing when I attempt to enable tracing?

from chrysalisp.

Hi Martyn

Good luck with the snow !!!

I’ve merged the windows branch to master and done a full rebuild of the snapshot.zip.

I’ve cut down the tracing to just the class and gui functions for now. But let’s start with taking this as is and booting with your Windows host code. Ensure we see the GUI as before.

Then we need to double check that building with ChrysaLisp- you can reproduce an identical boot_image. Which should work, as it works here and we have the same code !

Then let’s enable the slightest bit of tracing for say one app and check that etc etc

Your very close now to everything running. The only thing I’m concerned about was that your running GUI froze on you and that a bit supisous. Could just mean we need a bigger per task stack on Windows, could be more serious. But we’ll get to the bottom of it.

Will I be ok to try your windows PR if I install the community edition visual studio on my Win10 laptop or do I need something more ‘purchased’ ?

Chris

from chrysalisp.

We should keep your PR on the Windows branch till we get it stable. Just to isolate things form folks grabbing the main branch. Baring finding some glaring problem we should be able to merge it all to master soon.

from chrysalisp.

Hey Chris, This sounds like a great plan! The community edition will work just fine. Looking forward to trying this out when I get back.

from chrysalisp.

Ok, back now. So I performed the tests you suggested.
With your latest code merged into my dev branch and your boot_image I get the GUI and actually it didn't freeze this time so that's awesome.

I built a boot_image with chrysalisp- but it produced a broken boot_image attached here for your perusal.

boot_image_bad.zip

from chrysalisp.

Mmmm, so we seam to have problem with the C++ Lisp on Windows ?

Do you have the ability to build by any other way than ChrysaLisp- ?

Also I need to get my Windows machine going with Visual Studio and try compiling the C++ Lisp !

Are you sure your 'platform' and 'arch' files are saying 'Windows' and 'x86_64', not by any chance building a Windows Arm or anything odd like that ?

from chrysalisp.

Can you get thing ready for a PR while I get my Windows machine set up ?

With the working pre-built boot_image I put up, can you run everything on the GUI demos without problem ? If so can you try to launch the GUI terminal and just try some simple, like 'echo bert' then maybe 'cat README.md'

I don't see any obvious isssues with that boot_image_bad, so I'm going to do a full build with my mods for tonight and push them.

Can you verify that if you take that and use the Windows ChrysaLisp- to create a boot_image that diff says tha file contents are not the same ?

from chrysalisp.

My bad, I had a stale change to a .vp file that was causing the issue, undoing it allows me to self host!

from chrysalisp.

Does that mean that you can compile and build everything with ChrysaLisp- and things work ? And that you can build via the ChrysaLisp terminal ?

from chrysalisp.

I've only tried the first but yes it did work!

from chrysalisp.

OK, so how about trying a few of those simple GUI Terminal commands.

echo bert
cat README.md
echo bert | dump
echo bert | dump | dump
make doc
make all

??

from chrysalisp.

Everything except the make commands seemed to work:

from chrysalisp.

That's not bad though !

from chrysalisp.

So next suspect is going to be the host 'write' commands !

Try to run the Lisp interpreter with 'lisp' and then try the command (all-vp-files), just see if we can do a full make tree file search.

from chrysalisp.

My old Windows laptop is so slow, it still hasn't booted since I told you I was turning it on.... :(

from chrysalisp.

host gettime call is not correct judging by your GUI clock ;)

from chrysalisp.

hmmm good point :)

from chrysalisp.

I don't think this Windows Laptop I have is going to cut it ! Will need to bring my work machine home for this weekend. At least that has got Visual Studio installed already, so if you can do a PR I'll try to look into this over the weekend.

At least you can work on fixing gettime ;)

from chrysalisp.

yeh working on a PR now

from chrysalisp.

Another command to try, simple create/write to file with.

cat README.md | tee d

Do you get the 'd' file created and written ? If not then time to look into the host 'open' for write, and the 'file' write call ! The code for 'cmd/tee.lisp' is pretty simple.

from chrysalisp.

Got to call it for tonight, sorry to leave you hanging, but I will start looking again as soon as I get back from office tomorrow with a Windows Laptop that Fred Flintstone didn't own :)

from chrysalisp.

No problems - submitted a PR but I think i've messed it up :( Let me know if you need me to change anything.

from chrysalisp.

This works 'cat README.md | tee d' - I do indeed get the file created with the contents of README.md

from chrysalisp.

Problem in (all-vp-files) is that after a few valid calls through stat and open we get 'sys/make.inc)\r' which then causes stat to return an error ode

from chrysalisp.

Yup the PR was a problem :) See the PR for issues.

Mmmm, that filename of 'sys/make.inc)\r' is odd. Clearly should be just 'sys/make.inc', and the '\r' is odd too but could just be corruption.

from chrysalisp.

Could this simply be that you have CR/LF the text files ? Have you got your GIT converting text file line endings to CR/LF for windows or your editor doing this ?.......

(stream-readline) is going to pull everything till the LF, but I'm not sure what would happen in the parsing if it has a CR on the end of the line ! Maybe we just found out.

from chrysalisp.

I just converted my 'make.inc' file in the root to be CR/LF and yup, problems ! So I think we have a winner.

Plus I think I should make the parser immune to this issue now you've spotted my deliberate mistake ;)

from chrysalisp.

Pushed fix to strip CR from lines. I hope that means you can now run all the make commands !

make doc
make all
make platforms
make boot
make all platforms boot

Chris

from chrysalisp.

They all work now except the last one which ends up jumping off into the weeds. I'm also seeing a memory leak (for the first time) which ill track down at some point

from chrysalisp.

Got your zip and have now got it compiling and running!

I’ve got the same instability running the make commands so over the weekend I will do my best to track down what is happening !

Good job Martyn!

from chrysalisp.

No problems :) Good luck!

from chrysalisp.

Let me know if you want me to look at anything

from chrysalisp.

Just push the Windows branch with a working Windows GUI and exe. !

I took the liberty of doing a major tidy up on the main.c and removing the winnmap files.

I've created starting run.bat and stop.bat file, and a run_tui.bat that currently doesn't work, but I'll get round to it shorty.

Have to have your .dll's for DSL and DSL_ttf etc in the windows path or pop them in the ChrisaLisp folder.

The big issue was return values from Windows as int's not being promoted to long long's int the open/read/write functions, and the file mode no being correct for windows O_CREATE action.

Many thanks Martyn for giving us all the benefit of the Windows version !!!

Chris

from chrysalisp.

I've merged everything over to Master now it's stable. And deleted the windows branch.

Things left to do for the Windows version:

1. get the TUI launch working. This means fixing the issue with none blocking read from stdin, or switch to a more abstract way of doing that so Windows can deal with the idea directly.

2. set up a virtual network inside run.bat and run_tui.bat to match the 10 CPU setup of run.sh. Don't see the need to go full on with all the virtual network topologies yet on Windows but want to get some extra threads going.

3. as a result of 2, implement the shared link driver memory for Windows...

4. fix gettimeofday so that it actually does the correct time ;)

OK, I'm calling it a day now, got shopping to do.

from chrysalisp.

Very cool, nice work!

from chrysalisp.

Which version of visual studio are you testing with? I had to make some changes to build without errors on vs 2017

from chrysalisp.

I've got Visual Studio 2017 here on the work laptop, it also has 2015 compiler installed as well. I notice 2 warnings when I compile. What errors did you see. ?

from chrysalisp.

vsfiles.zip

Here are the VS file I made for the project, they just go in the ChrysaLisp folder.

from chrysalisp.

And I put the SDL dev folder just unziped on C:

from chrysalisp.

The errors were because the posix functions weren't starting with a leading underscore. I'll try your solution later

from chrysalisp.

Your solution and main.c build just fine here. My solution with your main.c gives me the errors I mentioned:

1>------ Build started: Project: ChrysaLisp, Configuration: Debug x64 ------
1>main.c
1>c:\users\spiri\chrysalisp\main.c(31): error C4996: 'open': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _open. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(516): note: see declaration of 'open'
1>c:\users\spiri\chrysalisp\main.c(32): error C4996: 'open': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _open. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(516): note: see declaration of 'open'
1>c:\users\spiri\chrysalisp\main.c(33): error C4996: 'open': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _open. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(516): note: see declaration of 'open'
1>c:\users\spiri\chrysalisp\main.c(49): warning C4013: 'kbhit' undefined; assuming extern returning int
1>c:\users\spiri\chrysalisp\main.c(51): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
1>c:\users\spiri\chrysalisp\main.c(51): error C4996: 'read': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _read. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(523): note: see declaration of 'read'
1>c:\users\spiri\chrysalisp\main.c(56): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
1>c:\users\spiri\chrysalisp\main.c(56): error C4996: 'write': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _write. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(558): note: see declaration of 'write'
1>c:\users\spiri\chrysalisp\main.c(170): warning C4090: 'initializing': different 'const' qualifiers
1>c:\users\spiri\chrysalisp\main.c(207): error C4996: 'close': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _close. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(459): note: see declaration of 'close'
1>c:\users\spiri\chrysalisp\main.c(209): error C4996: 'unlink': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _unlink. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(553): note: see declaration of 'unlink'
1>c:\users\spiri\chrysalisp\main.c(231): warning C4244: 'function': conversion from '__int64' to 'int', possible loss of data
1>c:\users\spiri\chrysalisp\main.c(231): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
1>c:\users\spiri\chrysalisp\main.c(239): warning C4244: 'function': conversion from '__int64' to 'int', possible loss of data
1>c:\users\spiri\chrysalisp\main.c(231): error C4996: 'read': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _read. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(523): note: see declaration of 'read'
1>c:\users\spiri\chrysalisp\main.c(239): error C4996: 'close': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _close. See online help for details.
1>c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\corecrt_io.h(459): note: see declaration of 'close'
1>Done building project "ChrysaLisp.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

But as yours works its not a problem.

from chrysalisp.

I think we can close this out now do you agree?

from chrysalisp.

Yup :)

The remaining bits and bobs on Windows will get sorted over time and have there own issue raised.

Again, many thanks Martyn for the push on this and for joining the porting club ;)

Chris

from chrysalisp.