martinmcclure / mist Goto Github PK

For some reason, I'm seeing three executables left in my image directory after running tests:

• testConsume1
• testFortyTwo
• testThreePlusFour

Each test is supposed to remove its executable after running; don't know why those three aren't.

The x86_64 ABI lists rbp as " callee-saved register; optionally used as frame
pointer. Currently, Fog uses rbp as a frame pointer, accessing temporary variables relative to rbp.

However, this is optional, and I've since learned that C does not use rbp this way. C essentially uses rsp as a frame pointer, leaving rbp free for other uses. We should do the same.

Loading baseline of BaselineOfMist...
164Fetched -> Mist-MartinMcClure.59 --- filetree:///home/travis/dalehenrich-builderCI-b07190e/builds/travisCI/git_cache/mist/packages --- filetree:///home/travis/dalehenrich-builderCI-b07190e/builds/travisCI/git_cache/mist/packages
165FogX64LocationPreferences>>nextAvailableLocation (compiler is Undeclared)
166
167FogTests class>>consume1 (Fog is Undeclared)

...looks like something's not getting loaded correctly.

OTOH, Travis claims that 6 tests passed, which must have been the disassembler tests. Since those also compile, and would need the same stuff working, I'm not sure what's going on.

The Fog functional tests must currently each be run manually. Each creates an executable which must be run and the answer checked by hand.
As the number of tests increases, it would be increasingly nice to have the tests fully automated using SUnit, interacting with OSProcess or something to invoke the executables that the test produces.

I'm not likely to do this anytime soon, since I don't have experience with OSProcess and should probably focus on pushing other areas forward. However, it would (hint hint) make a great first contribution for someone.

In order to have multiple routines, and to link them together, we need the process of compiling and installing a module to be roughed in.

Steps in installing a module, as currently envisioned:

1. Install all prerequisite modules. Detect any erroneously circular requisites.
2. Process all definitions for classes or module variables, creating empty classes for each class definition.
3. Compose the classes recursively to know what instvars and methods each class has. This process also detects erroneously circular class composition. Empty methods are created, and deltas are recorded for each affected selector's method dictionary.
4. Compile each method, leaving inline caches empty (0).
5. Fill in the guess for each send site's inline cache.'
6. Make the methods live by applying the deltas recorded earlier to the method dictionaries of the affected selectors.

The bootstrap should be moved from Pharo 1.4 to Pharo 2.0.

Add a conditional node to Fog. Initial specification (comments/suggestions welcome):

A Fog conditional node is created with the message

Fog
following:
if:
then:
else:

The 'following' tree is executed. This is an arbitrary subtree, but its ultimate purpose is to set or clear a CPU condition flag. The specified CPU condition flag (#Z, #N, #C, #V, #notZ, #notN, #notC, #notV) is then tested. If the condition is met, the 'then' subtree is executed, otherwise the 'else' subtree is executed.

"Fog Loops, part of this balanced breakfast!"

Well, not quite. Now that Fog has conditionals, the main missing feature is loops.

Initial design:
Loop node -- has an arbitrary number of children. Executes those children sequentially, then repeats. Forever, unless terminated by...

Loop exit node -- references a Loop node (probably through a unique object used as a label). Has one child. Evaluates that child, then exits from the loop node, giving the result of its child as the result of the loop.

At Smalltalks, Igor suggested that I use AsmJit for the Mist assembler -- "We don't need two x86_64 assemblers written in Smalltalk". It does look like AsmJit (currently on SqueakSource) is more complete than the Mist assembler.

So: Look into it, see whether its architecture is reasonably compatible, and use it if so.

There's now enough code to break into multiple packages and manage them with Metacello. With the possible adoption of AsmJit and the imminent move from work on Fog to work on actual Mist objects, even more so.

Now that 64-bit tests on TravisCI are working, all tests are passing on Pharo 1.4, but three of the disassembler tests are failing on Squeak 4.3. Since all of the Fog tests and most of the disassembler tests are passing, I'm guessing that this is something minor.

So if someone who actually runs Mist on Squeak wants to diagnose this, that'd be great. Does anyone run Mist on Squeak? If not, I'll disable the automatic Squeak tests.

At ESUG, there was interest in running Mist on Mac. For now, I'm going to focus on expanding Mist functionality in Linux, but I'd be happy to integrate Mac functionality if someone wants to get that working.

Preliminary investigation (see Wiki page "OSX Resources) indicates that syscalls are probably the same or nearly so. The primary task to get it running on a Mac seems to be outputting as a Mach-O executable rather than an ELF executable.

To anyone who picks this issue up: Look at the ElfFile example #fortyTwo -- if you can get those bytes into a Mach-O file that OS X will execute and return exit code 42, I should be able to integrate that into the main code base.

The general goal for the disassembler is to, at any point in time, be able to disassemble anything that the Fog compiler can create. It will probably never have to disassemble the entire x86_64 instruction set.

The old disassembler was based on OMeta, which worked in Pharo 1.2 but doesn't load into Pharo 1.4. Also, it was becoming obvious that the number of productions required was going to be enormous.

Therefore, the old disassembler got ripped out before the code got moved to Github. The new disassembler is table-driven, but is only half complete. This issue exists to track the branch for the disassembler's completion.

Right now, the back end of the Mist compiler is successfully turning Fog into a short executable program. There are no objects, classes, methods, or even subroutines.

The next step is to produce an ELF file with two objects in it, a startup routine and a method. The method will be a primitive. The startup routine will be one that starts Mist by initializing the stack pointer and calling the designated startup method. When (if) that method returns, the startup routine will check to see whether it returned a SmallInteger in the C int range. If it did, that will be the exit status of Mist. Otherwise, the exit status will be 1.

For the primitive, I'll probably convert each of the existing Fog tests to produce a primitive method, at which point the existing Program node will be obsolete and can be retired.

The fetch byte Fog node currently xors the destination register with itself to zero it, then loads the low-order byte with a mov instruction. The movzx instruction could do this in one instruction.