Home

Welcome to the Strongtalk wiki!

Resources

https://code.google.com/p/strongtalk/

Mailing lists

https://groups.google.com/forum/#!forum/strongtalk-general https://groups.yahoo.com/neo/groups/strongtalk/info

Benchmarking

all benchmarks call code already in the image, would be best to keep it all in the script file

disable frequency scaling and https://xion345.github.io/2015/08/08/reliable-laptop-benchmarks-solution.html https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-32-ia-64-benchmark-code-execution-paper.pdf

Assembly

The bytecode interpreter is written in assembly. There are .S files in. These are currently dead code. Instead, the machine code is being generated at VM startup. I am not sure why this is a better approach, but V8, Dart VM and Self do it this way as well. Probably because the code generation is there because of the JIT, so why not reuse it. are the same rutines used by the JIT.

It is IA-32 assembly. The assembler uses Intel syntax.

http://x86asm.net/articles/what-i-dislike-about-gas/ good to-the-point overview and comparison of the syntaxes (my take on that is Prefer neither, write in C ; )

Clean-ups

-fpermissive

This allows taking addres of a temporary. WHich is a bad thing https://gcc.gnu.org/onlinedocs/gcc/Temporaries.html#Temporaries

-ffriend-injection

Clang does not support the flag.

Precompiled headers

Needs measuring. How much time does it save? Alternatives are do nothing, use ccache.

Makedeps

Specify all includes in a special file, the include databases, the tool then computes their topological ordering for each file. It replaces include guard defines. As a downside, one cannot include a header twice this way even if it is intended. Also conditional inclusion is not possible (maintaining multiple include databases for each OS is what is done, but it IMO sucks). It is nice to have it all in a single file.

Generally it is hard to ensure files include only what they need and all they need. https://gcc.gnu.org/wiki/ModularGCC

alternatively, use include guards or pragma once (gcc and clang support it), would be lot of menial work.

Debugging

http://reverseengineering.stackexchange.com/a/1936 GDB assembly tutorial on Stack Exchange https://sourceware.org/gdb/current/onlinedocs/gdb/ GNU documentation is far from being "glanceable", but knowing GDB well pays off

si; ni; advance; layout asm; layout regs; finish (don't use return)

(debugger in KDevelop does not have views for debugging assembly. AFIR, QTDevelop does. There are other GDB frontends.)

That means the generated assembly. Use si and ni.

Set breakpoints with break *address. I observed that addresses do not change in-between runs. It is necessary to first let the VM generate the assembly routines, only then it is possible to put a breakpoint there.

b main.cpp:167
b *0xf6421552

Some GDB's commands (notably step and next) skip lines for which there is not available source code.

advance *0xf6421552

https://www.cs.virginia.edu/~evans/cs216/guides/x86.html Sihgle page overview

https://en.wikibooks.org/wiki/X86_Assembly https://en.wikibooks.org/wiki/X86_Disassembly

IA-32 manual https://www-ssl.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html; https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Inline assembly

https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html http://clang.llvm.org/compatibility.html#inline-asm

valgrind

http://valgrind.org/docs/manual/manual-core.html

--smc-check=all-non-file; the default (stack) is not enough, because the jitted code is on the heap. AFIK, there are no memory mapped files in Strongtalk. This option makes Valgrind slow, but it is absolutely necessary to add it, otherwise valgrind executes nonsense.

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html (přesměrování výstupu)

valgrind --smc-check=all-non-file ./strongtalk-test -b ../strongtalk.bst

then various combinations of --suppressions=../ci/valgrind.supp --db-attach=yes --track-origins=yes

--undef-value-errors=no

Use of uninitialized values: the problems seem real and it is (in the two cases I investigated yet) caused in the generated machine code. Uggg! Strangely, the strongtalk program (hello world) runs just fine. It is necessary to investigate in the real interpreter, the strongtalk-test might cause additional such errors by being sloppy about mocking. Time investigating those would be perfectly wasted. Memcheck is awfully slow. It is always best to find the erroneous values with asserts and breakpoints. It is good that addresses do not change in between runs. https://stackoverflow.com/questions/5194666/disable-randomization-of-memory-addresses

Memory leaks: all I've seen are either "singletons" that are created during startup and the VM does not bother freeing during shutdown (which is quite harmless, there is object pool working this way that never frees memory, this could be a problem in a long running application) or those are not reclaimed pthread objects (I am now setting threads as detached, should be fine) or ... TBC ...

Bool problem Problem https://groups.google.com/d/msg/strongtalk-general/CpCBOWoHD2w/08X520YsBBkJ https://code.google.com/p/strongtalk/source/browse/trunk/vm/compiler/expr.hpp?r=24#36 Solution https://groups.google.com/d/msg/strongtalk-general/ssGwU8FtR6g/MLyzV-_MqR4J Commit https://code.google.com/p/strongtalk/source/detail?r=32

CLI

https://code.google.com/p/strongtalk/source/detail?r=42 https://code.google.com/p/strongtalk/source/detail?r=93

JITs

http://www.masonchang.com/blog/2010/3/12/have-tracing-jit-compilers-won-notes.html

there is obviously LLVM, GCC has libgccjit, although it is one-man-job and Linux only. GNU libJit,

Machine code generation

there is GNU lightning multiplatform assembler, DynASM (used by LuaJIT), see https://stackoverflow.com/questions/1413734/most-portable-library-for-dynamic-code-generation for more or try plugging in assembler code from V8 or Dart VM. Or work with whats there and just make it adhere to the calling convention (saving stack frames and registers as it should). Building on other code is not so great, because I wont be able to reuse their jit, so I might just go all the way with llvm anyway.

probably try everything (in branches, starting with reusing Dart) and see which works best for me

Static analysis

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

clang-analyze works, build with

scan-build cmake..
scan-build make -j4

cppcheck http://cppcheck.sourceforge.net/manual.html

$ cppcheck --includes-file=includes.txt --platform=unix32 --quiet vm

includes.txt can be extracted from CMakeLists.txt

--includes-file=<file>
--inconclusive
--platform== unix32 win32A win32W
--quiet

i thought the 100 character limit on class names is a thing of the past https://code.google.com/p/strongtalk/source/detail?r=200

scan.coverity.com

it is configured to scan every commit to the coverity branch after travis builds it

https://github.com/myint/cppclean

continuous integration

drone.io and travis-cl; should probably make a ci directory and put build scripts there, as opposed to having them in config file (travis) or outside the repository in drone.io website. it would also serve as a quick reference how to build the software

dynamic checkers

gcov, valgrind and --analyze=* do not work, instrumented runs make the program take a different codepath than noninstrumented and it sooner or later crashes. I guess because the generated assembly is careless about maintaining the stack.

calling conventions are described in asm wikibooks and (for Linux) in http://www.uclibc.org/docs/psABI-i386.pdf

http://www.jarober.com/blog/blogView?showComments=true&title=Smalltalk+Criticism&entry=3486794128 http://richardkulisz.blogspot.cz/2011/02/smalltalk-software-industrys-greatest.html

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf