This thesis presents a tool for SPEcification based teSTing (SPEST). SPEST is designed to use well known practices for automated black-box testing to reduce the burden of testing on developers. The tool uses a simple formal specification language to generate highly-readable unit tests that embody best practices for thorough software testing. Because the specification language used to generate the assertions about the code can be compiled, it can also be used to ensure that documentation describing the code is maintained during development and refactoring. The utility and effectiveness of SPEST were validated through several exper- iments conducted with students in undergraduate software engineering classes. The first experiment compared the understandability and efficiency of SPEST generated tests against student written tests based on the Java Modeling Lan- guage (JML)[25] specifications. JML is a widely used language for behavior program specification. A second experiment evaluated readability through a sur- vey comparing SPEST generated tests against tests written by well established software developers. The results from the experiments showed that SPEST’s specification language is at least understandable as JML, SPEST’s specification language is more readable than JML, and strongly suggest that SPEST is capable of reducing the effort required to produce effective tests.

Vale is a multi-purpose programming language that focuses on guaranteeing memory safety with minimal effect on performance. To accomplish this, Vale utilizes a memory management system called Hybrid Generational Memory (HGM). HGM uses generational references to track the state of objects in memory, and static analysis to reduce memory management overhead at runtime. This thesis describes the program that performs static analysis on Vale source code during compilation, and analyzes its effect on the performance of Vale programs.

Automatic Heterogeneous Compilers allows blended hardware-software solutions to be explored without the cost of a full-fledged design team, but limited research exists on current partitioning algorithms responsible for separating hardware and software. The purpose of this thesis is to implement various partitioning algorithms onto the same automatic heterogeneous compiler platform to create an apples to apples comparison for AHC partitioning algorithms. Both estimated outcomes and actual outcomes for the solutions generated are studied and scored. The platform used to implement the algorithms is Cal Poly’s own Twill compiler, created by Doug Gallatin last year. Twill’s original partitioning algorithm is chosen along with two other partitioning algorithms: Tabu Search + Simulated Annealing (TSSA) and Genetic Search (GS). These algorithms are implemented inside Twill and test bench input code from the CHStone HLS Benchmark tests is used as stimulus. Along with the algorithms cost models, one key attribute of interest is queue counts generated, as the more cuts between hardware and software requires queues to pass the data between partition crossings. These high communication costs can end up damaging the heterogeneous solution’s performance. The Genetic, TSSA, and Twill’s original partitioning algorithm are all scored against each other’s cost models as well, combining the fitness and performance cost models with queue counts to evaluate each partitioning algorithm. The solutions generated by TSSA are rated as better by both the cost model for the TSSA algorithm and the cost model for the Genetic algorithm while producing low queue counts.

WebAssembly is an instruction set designed for a stack based virtual machine, with an emphasis on speed, portability and security. As the use cases for WebAssembly grow, so does the desire to target WebAssembly in compilation. In this thesis we present Rasm, a Racket to WebAssembly compiler that compiles a select subset of the top forms of the Racket programming language to WebAssembly. We also present our early findings in our work towards adding a WebAssembly backend to the Chez Scheme compiler that is the backend of Racket. We address initial concerns and roadblocks in adopting a WebAssembly backend and propose potential solutions and patterns to address these concerns. Our work is the first serious effort to compile Racket to WebAssembly, and we believe it will serve as a good aid in future efforts of compiling high-level languages to WebAssembly.

Optimization by a compiler can be executed with many different methods. The defence company Saab provided us with a mission, to see if we could optimize their code with the help of the GCC compiler and its optimization flags. For this thesis we have conducted a study of the optimization flags to decrease the worst case execution time. The first step to assemble an effective base of flags was reading the documentation for the flags. We then tested the different flags and analysed them. In the end we ended up with four chosen sets that we saw fitted to be discussed and analyzed further. The results did not live up to our expectations, as we thought the flags would optimize the execution time. The flags int he majority of cases gave an, although small, increase of the execution time. We only had one set where the flags gave us a decrease, which we called the Expensive Optimization.With these results we can conclude that Saab do not need to change their existing set of optimization flags to optimize their compiler further.

Un défi majeur pour les programmeurs, en particulier pour les novices, est de comprendre les messages d'erreurs émis par le compilateur. Nous nous intéresserons au problème d'affichage de bon message d'erreur de compilation. Dans certains langages, tels que Typer, la vérification du type des expressions est faite lors de la compilation; ce qui oblige le compilateur à déduire les types de certaines ou de toutes les expressions; mais aussi d'envisager la meilleure manière d'écrire le type (dans le langage source) dans un message d'erreur (ce qui est infaisable pour le moment dans Typer). Cependant l'interprétation du type des expressions faite par le compilateur est toujours différente de ce que l'utilisateur aimerait voir en cas d'erreur de compilation. En effet, lorsque le code source est converti en une représentation interne via une fonction complexe (appelée \Code{elaborate}), il peut être difficile de trouver une correspondance entre le type "t\_source" (type du code source) et le type "t\_interne" (type de la représentation interne du code source) en cas d'erreur. Parfois, "t\_source" peut ne pas être disponible ou même n'avoir jamais existé car "t\_interne" a été créé de toute pièce par inférence de type. Il peut donc être difficile de trouver un "t\_source" correspondant, d'autant plus qu'il doit être clair et compréhensible pour le programmeur. En d'autres termes, il n'existe pas d'algorithme déterministe permettant de trouver une représentation naturelle dans le code source correspondant à la représentation interne d'un type. D'où l'importance d'implémenter un système heuristique tel que les algorithmes génétiques ou les réseaux de neurones qui nous donne cette information, permettant ainsi une meilleure affichage du texte des messages d'erreurs. Nous avons donc décidé de travailler sur l'amélioration des messages d'erreur du compilateur Typer, dans sa phase de traduction du langage (interprétation et représentation des différentes expressions dans le langage source) en proposant une approche basée sur les algorithmes génétiques. \\ / A major challenge for programmers, especially for novices, is to understand the error messages issued by the compiler. We are interested in the problem of displaying correct compiler error messages. In some languages, such as Typer, the type checking of expressions is done at compile time; this forces the compiler to deduce the types of some or all expressions; but also to consider the best way to write the type (in the source language) in an error message (which is unfeasible for the moment in Typer). However, the interpretation of the type of expressions made by the compiler is always different from what the user would like to see in case of a compilation error. Indeed, when the source code is converted into an internal representation via a complex function (called ‘elaborate’), it can be difficult to find a correspondence between the type "t_source" (type of the source code) and the type "t_interne" (type of the internal representation of the source code) in case of error. Sometimes, "t_source" may not be available or even have never existed because "t_interne" was created from scratch by type inference. It can therefore be difficult to find a corresponding "source_t", especially since it must be clear and understandable for the programmer. In other words, there is no deterministic algorithm to find a natural representation in the source code corresponding to the internal representation of a type. Hence the importance of implementing a heuristic system such as genetic algorithms or neural networks that gives us this information; thus allowing a better display of the text of error messages. We therefore decided to work on the improvement of the error messages of the Typer compiler, in its language translation phase (interpretation and representation of the different expressions in the source language) by proposing an approach based on genetic algorithms.

No description available.

No description available.

No description available.

No description available.