• Print
• Login

Requirements

Requirements

In this section, we describe the main requirements that we have for GPMachine. Those requirements are not exhaustive and your contributions are welcome. All of them are not matched in the current version. I will appreciate any help in improving and/or implementing unmatched requirements. Do not hesitate to contact us .

• 1) GPMachine shall be usable by students and help them in understanding the "Syntaxe & Sémantique" Course.
  • 1.1) Accessibility:
    • 1.1.1) GPMachine shall run on most platforms used in Namur: Linux, Windows, Mac and Solaris. We suppose that a recent java environment (at least jre 1.4) exists on these platforms. (v1.1 OK)
    • 1.1.2) GPMachine shall be free. (v1.1 OK)
    • 1.1.3) GPMachine shall be easy to install. (v1.1 OK)
    • 1.1.4) GPMachine shall provide a Graphical User Interface allowing students to
      • 1.1.4.1) Visualize the execution of their PCode. Stack content, Instruction Memory, Input/Output and Heap content must be visible. (v1.1 OK, except for heap)
      • 1.1.4.2) Load PCode, from file, using standard file selection mechanisms. (v2.0 ok)
      • 1.1.4.3) Modify PCode on-the-fly. The execution will use this modified PCode.
      • 1.1.4.4) Support two execution modes: running and step-by-step. In running mode, breakpoints can be defined. When a breakpoint is met, the running mode pauses and the user can switch to step-by-step mode or resume execution. (v1.1 OK, supports big step mode: user can select an amount of statements to execute before the next pause)
    • 1.1.5) The GPMachine distribution shall contain a user manual describing at least. This manual shall be available in different formats (man page, texinfo, html, pdf). This will help ensuring that GPMachine is self-contained:
      • 1.1.5.1) The Installation procedure
      • 1.1.5.2) The input file format and the PCode language (syntax/semantics)
      • 1.1.5.3) The use of the graphical user interface
      • 1.1.5.4) A synopsys and description of the command-line interface (options, etc).
  • 1.2) Standard compliance
    • 1.2.1) Students must be able to use GPMachine to test every example presented in the theoretical course. GPMachine should contain all instructions from Wilhelm and Maurer (v1.1 partly OK).
      • add i
      • sub i
      • div i
      • mul i
      • neg i
      • and b (type modifier needed from v2.0)
      • or b (type modifier needed from v2.0)
      • not b (type modifier needed from v2.0)
      • equ {i,b}
      • geq {i,b}
      • leq {i,b}
      • les {i,b}
      • grt {i,b}
      • neq {i,b}
      • ldo {a,b,i}
      • ldc {a,b,i}
      • ind {a,i,b}
      • sro {a,i,b}
      • stp {a,i,b}
      • ujp
      • fjp
      • ixj
      • ixa
      • inc {a,i}
      • dec {a,i}
      • chk
      • dpl {a,b,i}
      • ldd
      • sli
      • new {a,b,i} (from v2.0)
      • lod {a,b,i}
      • lda {a,b,i}
      • str {a,b,i}
      • mst
      • cup
      • ssp
      • sep
      • retf
      • retp
      • movs
      • movd (not in v2.0)
      • smp (not in v2.0)
      • cupi (not in v1.1)
      • mstf (not in v1.1)
    • 1.2.2) PCode must be human-readable, under any text editor.
• 2) GPMachine shall be usable by teaching assistants to test student's submissions to practical works (TP).
  • 2.1) GPMachine can be installed on Automate (see Vincent Letocart).
    • 1.1.1) GPMachine runs under Linux Debian. (v1.1 OK)
    • 2.1.2) GPMachine provides a command-line interface, directs its output to stdout and reads its input from stdin.(v1.1 OK)
• 3) GPMachine shall help students in improving/debugging their compilers.
  • 3.1) Link back PCode to the original source code. By providing some additional information in the PCode (in comments), it shall be possible to open up the source file from which the PCode has been generated (from the GPMachine GUI) and jump to the line where the PCounter currently resides. This way, students can track the execution of the GPMachine in the source code.
  • 3.2) GPMachine shall perform type-checking when executing. This will help in ensuring that the running code is correct, i.e. that errors will be discovered as soon as possible. (v1.1 OK)
• 4) GPMachine shall be maintainable.
  • 4.1) Regression tests shall be available: when GPMachine is modified it must be possible to check whether the new version passes the test. These tests shall be automated.
  • 4.2) Old versions of GPMachine must always be available.
  • 4.3) New developers and teaching assistants shall be able to understand and modify the code easily (within one day).
    • 4.3.1) Design shall be understandable. Design patterns shall be used and documented. (v2.0 60% OK)
    • 4.3.2) Standard libraries and language idioms shall be used. (v1.1 OK)
    • 4.3.3) Code shall be documented. Every class, every package and every public method shall be specified. This documentation shall be written in the code and generated with a free and portable tool, namely Doxygen (v2.0 30% OK).