<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 3:16 PM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">Eliot,<br><br>Re "I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc)."<br>
<br>Would an updated edition of Patterson and Hennessy be helpful here? My copy (like my c skills) is from 1993.<br></div></div></blockquote><div><br></div><div>nothing fundamental that affects Cog has changed in that time... it'll do just fine.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><br><br>t.<br><div><br>---- On Thu, 07 Nov 2013 13:54:03 -0800 <b>Eliot Miranda<<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></b> wrote ---- <br>
</div><div><div class="h5"><br><blockquote style="border-left:1px solid #0000ff;padding-left:6px;margin:0 0 0 5px"><div dir="ltr">Hi Timothy,<div><br><div>On Thu, Nov 7, 2013 at 12:33 PM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">Eliot,<br><br>Thank you so much for the reply.<br> <br>
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them.<br>This is a great opportunity to contribute and get my chops up in the process.<br><br> When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)<br>
</div></div></blockquote><div><br></div><div>I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc).</div>
<div><br></div><div>So first things first. Get the stack VM wokring in 64-bits.</div><div><br></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">
<br>From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.<br><br>I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.<br>
</div></div></blockquote><div><br></div><div>OK, but right now you'll want to be in Smalltalk, and for quite a while.</div><div> </div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">I am currently attempting to get the source code from <a href="http://www.squeakvm.org/squeak64/" target="_blank">http://www.squeakvm.org/squeak64/</a> <tt>Squeak-3.8a-2.src.tar.gz to compile on </tt>the pure 64 box. <br>
The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM.<br>In the back of my mind, I am wondering if this is even the right approach to take..<br>
</div></div></blockquote><div><br></div><div>It's not :-).</div><div> </div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">
What do you think is the best approach to take?<br></div></div></blockquote><div><br></div><div>Read the latest two articles on my blog (<a href="http://www.mirandabanda.org/cogblog/2013/09/05/a-spur-gear-for-cog/" target="_blank">A Spur gear for Cog</a> & <a href="http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/" target="_blank">Lazy Become</a>).</div>
<div>Make a VMMaker image (see e.g. <a href="http://www.google.com/url?sa=t&rct=j&q=create%20a%20cog%20vmmaker%20image&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.mirandabanda.org%2Fcogblog%2Fbuild-image%2F&ei=sQp8UsnDL8GLjALn6oDICQ&usg=AFQjCNHoDMjPg2Sy7huxuOSDrTIyHo_RNw&sig2=s3vx6j1rl73gdHq37BMiiQ&bvm=bv.56146854,d.cGE" target="_blank">Cog Blog :: Building a Cog Development Image</a>).</div>
<div>Then read SpurMemoryManager, /especially/ its class comment.</div><div>Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested).</div><div>Then read SpurBootstrap32.</div>
<div>Try and create a 32-bit Spur image and run it.</div><div>Then try and implement SpurBootstrap64.</div><div>Try and create a 64-bit Spur image and run it.<br></div><div><br></div><div>This is /lots/ of work. In particular the last two steps require some significant design.</div>
<div>So start slowly and see how you get on.</div><div> </div><div><br></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">
Cordially,<br><br>t<br><div><br>---- On Thu, 07 Nov 2013 10:54:01 -0800 <b>Eliot Miranda<<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></b> wrote ---- <br></div><div><div> <br>
<blockquote style="border-left:1px solid #0000ff;padding-left:6px;margin:0 0 0 5px"><div dir="ltr">Hi Timothy,<br><div><br><br><div>On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?<br>
</div></div></blockquote><div><br></div><div>Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.</div>
<div><br></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif"><br>If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.<br>
</div></div></blockquote><div><br></div><div>How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.</div>
<div><br></div><div>It will be great to have another collaborator!</div><div><br></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">
<br>t.<br><br><br><br><br><div><br>---- On Thu, 07 Nov 2013 06:01:00 -0800 <b>Bob Arning<<a href="mailto:arning315@comcast.net" target="_blank">arning315@comcast.net</a>></b> wrote ---- <br></div><br><blockquote style="border-left:1px solid #0000ff;padding-left:6px;margin:0 0 0 5px">
<div text="#000000" bgcolor="#FFFFFF"><div> <font face="Georgia">It's absolutely none of my business what tools others choose to use, but I will say this:<br> <br> Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.<br>
<br> Cheers,<br> Bob<br> <br> </font> <div>On 11/7/13 8:28 AM, Igor Stasenko wrote:<br> </div> </div><blockquote><a href="mailto:Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" target="_blank">Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com</a>" type="cite"> <div>
<div><div dir="ltr"><br> <div><br> <br> <div>On 7 November 2013 08:58, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Tim and all,<br> <div> <div>On 07.11.2013, at 05:00, Ron Teitelbaum <<a href="mailto:ron@usmedrec.com" target="_blank">ron@usmedrec.com</a>> wrote:<br>
<br> > Hey Tim,<br> ><br> > Göran and Eliot have been discussing this. I just talked to Eliot about it<br> > yesterday. He said he was happy to support cmake but didn't want to have to<br>
> do the work himself. I'm hoping that the work Göran is doing on this now<br> > can be turned over to Eliot when it is finished. I think there is agreement<br>
> that combining the excellent work of pharo build with Eliot's new vm work is<br> > a very good thing to do. The work to merge the build environments is<br>
> already being done at 3D ICC. We are working on this for the Mac also but<br> > have not discussed it with Ian yet.<br> ><br> > Ron Teitelbaum<br>
><br> >> -----Original Message-----<br> >> From: <a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a> [mailto:<a href="mailto:squeak-dev-" target="_blank">squeak-dev-</a><br>
>> <a href="mailto:bounces@lists.squeakfoundation.org" target="_blank">bounces@lists.squeakfoundation.org</a>] On Behalf Of tim Rowledge<br> >> Sent: Wednesday, November 06, 2013 9:04 PM<br>
>> To: The general-purpose Squeak developers list<br> >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build<br> > process<br>
>><br> >><br> >> Wow, no interest? Is it because make is painful or because nobody needs to<br> >> make any more money?<br>
<br> <br> </div> </div> I actually have interest but I am currently reluctant,<br> for time-capturing reasons in my personal and work life.<br>
<br> However, Here is what I would do:<br> <br> • Start from Ians CMake work, and try to generalize it for the<br> non-Linux platforms<br>
• Windows would be kind-of straight-forward,<br> • For OS X, I would really want to have the Cocoa-based VM stuff<br> (aka Squeak VM 5.4.7.x) integrated and proper Xcode files<br>
generated, especially to be able to have iOS VMs built automatically.<br> Here, some information from John McIntosh would be helpfull, especially<br> a simple walk-through.<br>
I have some experience with that[1]<br> <br> <br> Despite all admiration I have for the way the PharoVM is built, there is one<br> thing that bothers me:<br>
• You first somehow generate the VM sources (which is fine, and the automated way is amazing)<br> • THEN, the a Script generates CMake-Files<br> • CMake then generates Makefiles<br>
• and then finally a vm is compiled.<br> This is one generating step too much, for my taste.<br> Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker,<br>
so that adding a new platform does not need to change the VMMaker…</blockquote> <div><br> </div> <div>The main big issue with 'platform-neutral' static source files, that they tend to<br>
</div> <div>grow with tons of #ifdef-s over time, reducing readability and creating a mess.<br> <br> </div> <div>My point is that one or another way you have to deal with platform differences,<br>
</div> <div>and the way how i prefer to do it is using smalltalk code,<br> </div> <div>but not .m4 files, or .cmake files, or writing a medium novel long configuration files<br>
</div> <div>using strange (better to say weird) scripting DSL.<br> </div> <div>I can express all build process logic in smalltalk, which does not lessens the amount<br>
of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it<br> into some manageable form, which is easy to change & learn.<br>
</div> <div> <br> </div> <div> And another difference is, that i prefer working with browser & classes than<br> with dozens of directories and files lying here and there.<br>
<br> </div> <div>But sure thing, it is a question of taste. If you prefer to maintain this:<br> -------------------------<br> MACRO (INTERNAL_PLUGIN plugin)<br>
SET (plugin_sources "")<br> IF (DEFINED ${plugin}_sources)<br> SET (plugin_sources ${${plugin}_sources})<br> ELSE (DEFINED ${plugin}_sources)<br>
FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins)<br> SET (tmp "")<br> AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp)<br>
STRING_APPEND (plugin_sources "${tmp}")<br> ENDFOREACH (dir)<br> ENDIF (DEFINED ${plugin}_sources)<br> IF (DEFINED ${plugin}_extra_sources)<br>
STRING_APPEND (plugin_sources "${${plugin}_extra_sources}")<br> ENDIF (DEFINED ${plugin}_extra_sources)<br> FILE (WRITE ${bld}/${plugin}/CMakeLists.in "")<br>
FOREACH (dir ${unix}/plugins ${unix})<br> FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake)<br> ENDFOREACH (dir)<br> FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake)<br>
CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY)<br> ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin})<br> ENDMACRO (INTERNAL_PLUGIN)<br>
--------------------------<br> </div> <div>And/or this:<br> --------------------------<br> AC_INIT([<a href="http://config.h.in" target="_blank">config.h.in</a>])<br>
<br> SVNREV=`grep '\$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \<br> | sed 's/.*$Rev: \([[0-9]][[0-9]]*\).*/\1/'`<br> AC_VM_VERSION(4,0,${SVNREV},4,2,0)<br>
<br> topdir=`cd ${srcdir}/../../..; pwd`<br> cfgdir=`cd ${srcdir}; pwd`<br> <br> AC_ARG_WITH(src,<br> [ --with-src=dir generated src directory [default=src]],<br>
[ vmmsrc="${with_src}"],<br> [ vmmsrc="src"])<br> <br> vmmdir="${topdir}/${vmmsrc}"<br> <br> if test ! -d "${topdir}/${vmmsrc}"; then<br>
if test -d "${topdir}/platforms/unix/${vmmsrc}"; then<br> vmmdir="${topdir}/platforms/unix/${vmmsrc}"<br> AC_MSG_RESULT([using built-in src directory])<br>
fi<br> fi<br> <br> AC_MSG_RESULT(${vmmdir})<br> <br> blddir=`pwd`<br> <br> AC_ARG_WITH(vmmcfg,<br> [ --with-vmmcfg=dir vm configuration directory containing <a href="http://plugins.int" target="_blank">plugins.int</a> and plugins.ext [default=.]],<br>
[ vmmcfg="${with-vmmcfg}"],<br> [ vmmcfg="${blddir}"])<br> <br> # Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.<br>
<br> AC_ARG_ENABLE(cogit,<br> [ --enable-cogit compile a cogit VM [default=yes]],<br> cogit="no", cogit="yes")<br> AC_SUBST(cogit)<br>
<br> #AC_ARG_ENABLE(jit,<br> #[ --enable-jit enable J4 support [default=no]],<br> #JIT="yes", JIT="no")<br> #<br>
#test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED"<br> #AC_SUBST(J_CFLAGS)<br> <br> # Check the generated src dir looks sane<br> <br>
AC_CHECK_VMM_DIR<br> <br> AC_SUBST(topdir)<br> AC_SUBST(cfgdir)<br> AC_SUBST(vmmdir)<br> AC_SUBST(vmmcfg)<br> AC_SUBST(blddir)<br>
<br> SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}<br> <br> AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")<br> <br> AC_SUBST(SQ_MAJOR)<br>
AC_SUBST(SQ_MINOR)<br> AC_SUBST(SQ_UPDATE)<br> AC_SUBST(SQ_VERSION)<br> <br> VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}<br> <br>
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")<br> <br> AC_SUBST(VM_MAJOR)<br> AC_SUBST(VM_MINOR)<br> AC_SUBST(VM_RELEASE)<br> AC_SUBST(VM_VERSION)<br>
<br> # libdir contains ${exec_prefix}, so we have to default and expand early<br> test "x$prefix" = xNONE && prefix=$ac_default_prefix<br>
test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'<br> imgdir=`eval echo ${libdir}/squeak`<br> expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}`<br>
plgdir='${imgdir}/'`eval echo ${VM_VERSION}`<br> <br> AC_SUBST(imgdir)<br> AC_SUBST(expanded_relative_imgdir)<br> AC_SUBST(plgdir)<br> <br>
AC_DEFINE(OS_TYPE, "unix")<br> <br> AC_CANONICAL_HOST<br> <br> host_cpu=`echo $host | sed 's,-.*,,'`<br> host=`echo $host | sed 's,-unknown,,'`<br>
<br> AC_SUBST(host)<br> AC_SUBST(host_cpu)<br> AC_SUBST(host_vendor)<br> AC_SUBST(host_os)<br> ----------------------------<br> <br>
</div> <div>instead of plain smalltalk code, it is up to you.<br> <br> </div> <div>But that's about 'too much' for my taste. <br> </div>
<div><br> </div> <div><br> </div> <div><br> </div> <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But if the community is positive to just move to the Pharo way of<br> building VMs, I'd be fine with that, since that would unify a lot<br> of infrastructure :)<br>
<br> Best<br> -Tobias<br> <br> [1] <a href="https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake" target="_blank">https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake</a><br>
<br> <br> <br> <br> <br> <br> <br> </blockquote> </div> <br> <br clear="all"> <br>
-- <br> Best regards,<br> Igor Stasenko. </div> </div> <br> <fieldset></fieldset> <br> <pre> </pre> </div></div></blockquote> <br> <br></div>
</blockquote><br></div></div><br><br> <br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div> </div></div> <br></blockquote><br></div></div></div></div><br><br> <br></blockquote></div><br>
<br clear="all"><div><br></div>-- <br>best,<div>Eliot</div> </div></div> <br></blockquote><br></div></div></div></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>