I found some support code for the ARM plugin, in the processors directory. Following the instructions, I noticed there was no step to run make in the sim/common directory, though it has a Makefile and contains .c files.
I carried on and when running make in sim/arm I received these errors multiple times:
../../include/libiberty.h:92:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PARAMS’ wrapper.c:135:20: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘VPARAMS’
Any help resolving this is received with gratitude.
Robert
On Oct 18, 2015, at 5:26 AM, Robert Withers robert.w.withers@gmail.com wrote:
I found some support code for the ARM plugin, in the processors directory. Following the instructions, I noticed there was no step to run make in the sim/common directory, though it has a Makefile and contains .c files.
I carried on and when running make in sim/arm I received these errors multiple times:
../../include/libiberty.h:92:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PARAMS’ wrapper.c:135:20: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘VPARAMS’
Any help resolving this is received with gratitude.
I ran into this problem when getting this to build on my 64-bit Ubuntu system. The problem is that the system’s ansidecl.h is incompatible with the one that should be used (in include/ansidecl.h in the ARM gdb directory). I fixed it by moving the include of ansidecl.h first before any other includes in the sim/arm/wrapper.c file:
/* TAO -- include local version of ansidecl.h first to ensure it is used instead of the system's version */ #include "ansidecl.h" #include "config.h" #include <stdio.h> #include <stdarg.h> #include <string.h>
— tim
Thank you, Tim! That fixed the issue and I now have a libsim.a.
I have a 64-bit machine and I installed 32-bit ubuntu. I'm sad about that and happy about this.
I am rebuilding the VM to see if the ARM plugin builds...which it did and I have that plugin.
Would you know the script to fire off an ARM simulation?
Received with great gratitude. Thank you, Robert
On 10/18/2015 09:04 AM, Tim Olson wrote:
On Oct 18, 2015, at 5:26 AM, Robert Withers <robert.w.withers@gmail.com mailto:robert.w.withers@gmail.com> wrote:
I found some support code for the ARM plugin, in the processors directory. Following the instructions, I noticed there was no step to run make in the sim/common directory, though it has a Makefile and contains .c files.
I carried on and when running make in sim/arm I received these errors multiple times:
../../include/libiberty.h:92:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PARAMS’ wrapper.c:135:20: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘VPARAMS’
Any help resolving this is received with gratitude.
I ran into this problem when getting this to build on my 64-bit Ubuntu system. The problem is that the system’s ansidecl.h is incompatible with the one that should be used (in include/ansidecl.h in the ARM gdb directory). I fixed it by moving the include of ansidecl.h first before any other includes in the sim/arm/wrapper.c file:
/* TAO -- include local version of ansidecl.h first to ensure it is used instead of the system's version */ #include "ansidecl.h" #include "config.h" #include <stdio.h> #include <stdarg.h> #include <string.h>
— tim
On Oct 18, 2015, at 8:41 AM, Robert Withers robert.w.withers@gmail.com wrote:
Thank you, Tim! That fixed the issue and I now have a libsim.a.
I have a 64-bit machine and I installed 32-bit ubuntu. I'm sad about that and happy about this.
I am rebuilding the VM to see if the ARM plugin builds...which it did and I have that plugin.
Would you know the script to fire off an ARM simulation?
check the README in Cog/image, and use buildspurtrunkvmmakerimage.sh and buildspurtrunkreaderimage.sh to build the two spur images. Then run your new VM on the SpurVMMaker.image. In the image are a bunch of squeak workspaces. Find the one titled “VM Simulation Workspace”. About 7 lines down in that workspace are two commented-out choices: “ISA ARMv5” and “ISA IA32”.
Start by uncommenting the ISA IA32 (remove quotes), then select everything from the beginning of the workspace to the line “cos openAsMorph; run)” and DoIt. This will open up a simulation (running the x86 interpreter) on the “spurtrunkreader.image” image. This runs for a little while for me before popping up an error message “Error: non-float was stored”. I temporarily got around that by clicking on Debug for the floatAt: and commenting out the “self error…” line, then doing a restart then proceed. Eventually you will get to a point where it will pop up a requester box labeled “Input please!”, which shows that the simulated image is running correctly.
You can then try running with the ARM simulator instead of the IA32 simulator by uncommenting it and commenting the ISA IA32 back again. However, you won’t get as far, as there are still problems with ARM simulation and Cog ARM code generation.
— tim
On 18-10-2015, at 9:06 AM, Tim Olson tim.olson.mail@gmail.com wrote:
You can then try running with the ARM simulator instead of the IA32 simulator by uncommenting it and commenting the ISA IA32 back again. However, you won’t get as far, as there are still problems with ARM simulation and Cog ARM code generation.
The sim is the biggest problem right now, but once some fixes from TimO get into the main svn tree that ought to improve. The actual code generation is pretty good - has to be or we wouldn’t be running a production Cog Spur VM on several million Raspbery Pis! - though we did spot an interesting bug in CPICs a week or so ago. I’m working on it with Eliot and I think we have a work-around fix and a better but more complex way to make CPICs better and simpler. Or something like that.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The generation of random numbers is too important to be left to chance.
On 10/18/2015 12:06 PM, Tim Olson wrote:
On Oct 18, 2015, at 8:41 AM, Robert Withers robert.w.withers@gmail.com wrote:
Thank you, Tim! That fixed the issue and I now have a libsim.a.
I have a 64-bit machine and I installed 32-bit ubuntu. I'm sad about that and happy about this.
I am rebuilding the VM to see if the ARM plugin builds...which it did and I have that plugin.
Would you know the script to fire off an ARM simulation?
check the README in Cog/image, and use buildspurtrunkvmmakerimage.sh and buildspurtrunkreaderimage.sh to build the two spur images. Then run your new VM on the SpurVMMaker.image. In the image are a bunch of squeak workspaces. Find the one titled “VM Simulation Workspace”. About 7 lines down in that workspace are two commented-out choices: “ISA ARMv5” and “ISA IA32”.
Yes, thanks very much, this is done. I'm running the spur image on my generated and built VM, with Bochs and ARM plugin support and plugins built externally.
Start by uncommenting the ISA IA32 (remove quotes), then select everything from the beginning of the workspace to the line “cos openAsMorph; run)” and DoIt. This will open up a simulation (running the x86 interpreter) on the “spurtrunkreader.image” image. This runs for a little while for me before popping up an error message “Error: non-float was stored”. I temporarily got around that by clicking on Debug for the floatAt: and commenting out the “self error…” line, then doing a restart then proceed. Eventually you will get to a point where it will pop up a requester box labeled “Input please!”, which shows that the simulated image is running correctly.
Oh, right, those are commented out. I ran the reader image a bit, in the simulator, and it crashed before the display had loaded. I'm not criticizing, that's awesome! Get it to work, get it to work right, get it to work fast or something like that. It's got latitude as attitude.
I still saw those comments as strings: I may only plead residual lingering cognitive distortions from the land of curly braces. Square brackets are subtle in their powers and it comes down to northern or southern style shaolin. And now I am just getting silly.
You can then try running with the ARM simulator instead of the IA32 simulator by uncommenting it and commenting the ISA IA32 back again. However, you won’t get as far, as there are still problems with ARM simulation and Cog ARM code generation.
How could I help with the simulation?
Thank you, Robert
— tim
On Oct 19, 2015, at 6:22 AM, Robert Withers robert.w.withers@gmail.com wrote:
You can then try running with the ARM simulator instead of the IA32 simulator by uncommenting it and commenting the ISA IA32 back again. However, you won’t get as far, as there are still problems with ARM simulation and Cog ARM code generation.
How could I help with the simulation?
I’ve ported the latest gdb version of the ARM simulator (gdb-7.10), which now includes support for VFP and other instructions that were missing from the gdb-7.6 version. That’s now in the queue awaiting final check and inclusion in the distribution. But there may likely be more debug work to get it running as well as the Bochs IA32 simulator.
I did run into issues trying to build the linux32x86 version on my 64-bit Ubuntu system: there are a number of system libraries that don’t have support for multiarch which I had to include local version of, and I had to put in some “-m32” flags in the config scripts to force the build to be 32-bit. Once the 64-bit Spur is stable, there will have to be some work to parameterize the simulator builds to build either 32-bit or 64-bit versions.
— tim
Hi Tim,
... ^^ robert
On 10/19/2015 09:00 AM, Tim Olson wrote:
On Oct 19, 2015, at 6:22 AM, Robert Withers <robert.w.withers@gmail.com mailto:robert.w.withers@gmail.com> wrote:
You can then try running with the ARM simulator instead of the IA32 simulator by uncommenting it and commenting the ISA IA32 back again. However, you won’t get as far, as there are still problems with ARM simulation and Cog ARM code generation.
How could I help with the simulation?
I’ve ported the latest gdb version of the ARM simulator (gdb-7.10), which now includes support for VFP and other instructions that were missing from the gdb-7.6 version. That’s now in the queue awaiting final check and inclusion in the distribution. But there may likely be more debug work to get it running as well as the Bochs IA32 simulator.
Where may I find alpha code forks like this gdb-7.10 support code, if just to practice building the lib and plugin. Perhaps I will be helpful here, but I have a lot of reading to do first; do another breadth-first scan, at some depth and with a little better awareness of all the current goals.
I did run into issues trying to build the linux32x86 version on my 64-bit Ubuntu system: there are a number of system libraries that don’t have support for multiarch which I had to include local version of, and I had to put in some “-m32” flags in the config scripts to force the build to be 32-bit. Once the 64-bit Spur is stable, there will have to be some work to parameterize the simulator builds to build either 32-bit or 64-bit versions.
My first task is to build a 64-bit Ubuntu system and jump in immersively.
Thank you,
Robert
— tim
Tim, the very first CogVMSimulator example has these options, including "ISA ARMv5" "ISA IA32":
CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit "SimpleStackBasedCogit" ObjectMemory Spur32BitCoMemoryManager "ISA ARMv5" "ISA IA32").
I am running the ARM simulation, right now?
Thanks, Robert
On 10/18/2015 09:04 AM, Tim Olson wrote:
On Oct 18, 2015, at 5:26 AM, Robert Withers <robert.w.withers@gmail.com mailto:robert.w.withers@gmail.com> wrote:
I found some support code for the ARM plugin, in the processors directory. Following the instructions, I noticed there was no step to run make in the sim/common directory, though it has a Makefile and contains .c files.
I carried on and when running make in sim/arm I received these errors multiple times:
../../include/libiberty.h:92:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PARAMS’ wrapper.c:135:20: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘VPARAMS’
Any help resolving this is received with gratitude.
I ran into this problem when getting this to build on my 64-bit Ubuntu system. The problem is that the system’s ansidecl.h is incompatible with the one that should be used (in include/ansidecl.h in the ARM gdb directory). I fixed it by moving the include of ansidecl.h first before any other includes in the sim/arm/wrapper.c file:
/* TAO -- include local version of ansidecl.h first to ensure it is used instead of the system's version */ #include "ansidecl.h" #include "config.h" #include <stdio.h> #include <stdarg.h> #include <string.h>
— tim
vm-dev@lists.squeakfoundation.org
-
Robert Withers -
Tim Olson -
tim Rowledge