[Vm-dev] Re: Uploaded squeak-vm 3.11.3

Fri Jan 29 22:47:06 UTC 2010

On 29 January 2010 19:02, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Thu, Jan 28, 2010 at 3:19 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> On 28 January 2010 06:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> >
>> >
>> > On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam <subbukk at gmail.com> wrote:
>> >>
>> >> On Wednesday 27 January 2010 08:56:07 pm Bert Freudenberg wrote:
>> >> > On 27.01.2010, at 05:37, K. K. Subramaniam wrote:
>> >> > > On Tuesday 26 January 2010 11:09:26 pm Bert Freudenberg wrote:
>> >> > >> Well, there is a source for this of course (in the VMMaker Squeak
>> >> > >> package). Generating the C code is a manual, interactive process and
>> >> > >> requires a running Squeak installation. Making that scriptable is
>> >> > >> possible, but so far nobody has done it AFAIK
>> >> > >
>> >> > > That is because most of the builds so far have been one target (which is
>> >> > > also the host). Batch builds are needed for multiple variants (e.g
>> >> > > debug/release) or when cross-compiling (say to ARM targets).
>> >> >
>> >> > Ian does batched cross-builds. But the source is still only generated once.
>> >> >  All targets use the same generated sources.
>> >> The generated files are not the "source". To reiterate the issue raised in the
>> >> bug report -
>> >> ---
>> >> the file platforms/unix/src/vm/interp.c starts with:
>> >>
>> >> /* Automatically generated from Squeak on an Array(9 May 2008 11:24:03 am)
>> >> by VMMaker 3.8b6 [...]
>> >>
>> >> However, I cannot identify the source file for that file. Also,
>> >> debian/copyright doesn't contain any hint how this file is generated.
>> >
>> > Indeed.  In the Teleplace VMs we generate e.g.
>> > /* Automatically generated by
>> >     CCodeGenerator VMMaker-eem.524 uuid: 9b748596-0986-4ca7-ac5b-b7a050a08431
>> >    from
>> >     SimpleStackBasedCogit VMMaker-eem.524 uuid: 9b748596-0986-4ca7-ac5b-b7a050a08431
>> >  */
>> > static char __buildInfo[] = "SimpleStackBasedCogit VMMaker-eem.524 uuid: 9b748596-0986-4ca7-ac5b-b7a050a08431 " __DATE__ ;
>> > char *__cogitBuildInfo = __buildInfo;
>> >
>> > where the UUIDs are those form the Monticello package.  If the package is dirty when the source file is output it gains an asterisk:
>> > /* Automatically generated by
>> >     CCodeGeneratorGlobalStructure * VMMaker-eem.519 uuid: 151cad6d-ee56-4458-a45d-a5c53502b5be
>> >    from    CoInterpreter * VMMaker-eem.519 uuid: 151cad6d-ee56-4458-a45d-a5c53502b5be
>> >  */
>> > static char __buildInfo[] = "CoInterpreter * VMMaker-eem.519 uuid: 151cad6d-ee56-4458-a45d-a5c53502b5be " __DATE__ ;
>> > char *__interpBuildInfo = __buildInfo;
>> > So we can determine both the Smalltalk source and the version of the generator that pushed out the C, or if it was an indeterminate version.  This is also available through the system parameter primitive.  Also note that tehthedate is the date of compilation, not generation, which should be immaterial.
>> >
>> >> ----
>> >> The "source" for this file is in embedded in vmmaker image. The header only
>> >> states that VMMaker was used as a tool but it is not evident that this version
>> >> of VMMaker also embeds the "source" for the interpreter (and the plugins). I
>> >> realize the tool and the sources are all one big blob in Squeak, but we still
>> >> need to consider interpreter and plugins as separate units during builds.
>> >>
>> >> So the questions that arise for downstream builders are :
>> >>
>> >>  a) Where is the information about generating this intermediate file from the
>> >> source? (i.e. tool, makefile, batch script)
>> >>  b) What is the license on that particular source unit which was used to
>> >> generate this intermediate file? Should all plugins use the same license as the
>> >> interpreter?
>> >>
>> >> In a manual process, these are all "in the head" but that doesn't help
>> >> downstream builders like Debian. In a batch process these steps are recorded
>> >> in scripts for anyone to read, follow and modify, if necessary.
>> >>
>> >> Isn't "generated source" an oxymoron :-)? I would favor getting rid of these
>> >> files from version control and go directly to filing Slang changesets into
>> >> VMMaker and translating them on the fly in Makefiles. I would even support
>> >> writing unix/ and Cross/ in Slang. Let C become the assembly language in
>> >> Squeak.
>> >
>> > Practically it is much more convenient to be able to gather all the C/C++ files together for a Vm build than it is to start form a set of C/C++ files and a Smalltalk source file and a Smalltalk image and a tool.  We keep an image containing a VMMaker in svn (in a directory image alongside platforms) and generate the vm/plugin tree form that image, updating it when VMMaker or a plugin is changed.  So a checking checks in the new source and the new image.  But if one wants to build one simply checks out the entire tree and builds, instead of having to fire up the VMMaker image.  Once Squeak is reliably headlessly scriptable across platforms one might revisit that but then you'd introduce a dependency of having to have a working VM to run VMMaker to punch out the sources, which could put a damper on developing for new platforms.
>>
>> That's really wrong. Ask yourself, what you would do with those C/C++
>> sources, while not having C compiler for new platform?
>
> I don't think it's wrong at all.  The current Squeak CVM is entirely dependent on having a C compiler.  If one doesn't have a C compiler one can't have a Squeak VM, i's as simple as that.  The platforms tree is C, the generated source is C.

If one doesn't have/can't run VMMaker, one couldn't have VM, its as
simple as that. ;)
It would be miracle if all what you would need to port Squeak on new
platform is to have just a C compiler and VM sources. But that's too
far from true. So, what the point in sticking with just C compiler
toolchain and pretending that we could avoid using VMMaker when
building VM?
C compiler is just a basic tool in toolchain, and being alone it
worthless , because as developer who porting VM you should have a full
access to every stage of VM building process, starting from VMMaker.
Its obvious!

I repeat: VMMaker _is_ a dependency, which we can't avoid, as well as
C compiler. And hindering it behind providing a pregenerated C sources
is really bad and misleading approach. A generated source don't have
any value if you can't access to tool which generating them.

> You have an argument only when the system becomes self-hosting, targeting either assembler or machine code, and there are a host of other issues lurking there such as what one uses for debugging, whether one has to generate debug info in the object code, etc, etc.  But for the current VM a C compiler is an absolute prerequisite.

You forgot about other prerequisites, including: make, gawk, CMake etc
etc. A whole host staying behind C tool chain.
But again, i'm not trying to dismantle the rule C compiler. I just
want to put VMMaker on top of it making it the first absolute
prerequisite above anything else.

>>
>> Yes! First, you will need to build a compiler binary for target
>> platform on a platform where compiler exists and can run, and only
>> then you could move inside and use it on new platform to compile
>> stuff. So, why it should be different for VM?
>
> Go ahead and change it.  But the current VM is based on the availability of a C compiler and so including the src tree in svn is perfectly reasonable.

Example: many of linux packages providing an html documentation. But
instead html format they using a bare-bone sgml or xml files, which
require an additional stages/tools to get an html docs out of them.
Moreover, some packages assuming that people know how to generate html
from sgml and even not including makefile rules for generating these
docs. Javadoc is another example..
Example2: yacc/byson sources. Same thing. A C code is generated from
corresponding .Y files and on my own experience porting projects on
windows, where i had only C compiler, i had first to get and build a
byson tool first.

So, what are you talking about? Instead of stating from very starting:
don't even think of building VM without VMMaker,
we including the pregenerated sources into svn tree, in this way,
making people think, that this is all what they need.
And then over and over again, every time someone new coming and asking
the very same question: WTF, VM can't be built? why my VM defunct? etc
etc..

>>
>> Migrating to new platform always means using some tool chain on
>> existing platform(s) to generate appropriate bootstrap code/binaries.
>> Sure , you can go without it, if you want to fall back to 60-70's era,
>> where no common tools existed and you had to work with binary data
>> manually and bootstrap from ZERO point. But that would be really
>> stupid and we should discourage people from porting VM in such way.
>>
>> > So while attractive in the abstract I think making the generated sources purely an intermediate form is a mistake.  In this case If It Ain't Broke Don't Fix It.
>> >>
>> >> Subbu
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>

-- 
Best regards,
Igor Stasenko AKA sig.