tricksterguy / complx Goto Github PK

This should allow users to customize the layout of the program

Write a shell script that automatically adds required repositories, installs dependancies, and compiles the program.

Some people like to type commands by hand (wat) and then make mistakes typing them.

This could turn into a possible job if I find problems with it.

Update the makefile so that comp is compiled and installed (if it hasn't already).

From Fall 2014 Feedback the scrolling on the memory view is too fast making it hard to scroll to an address.

Though I could argue to just use Ctrl+G.

Opening a memory view is kinda slow (about 2.5 seconds).
Investigate what causes the slowness and alleviate it.
Fixing this would also speed up opening complx itself.

Randomize clobbers all of memory including the trap vector table (and friends).

Think of a way to handle the case where student
Randomize + load file.
Set true traps.

This case will create three separate items to overlay into memory
The randomized memory
The students code
The trap vector table / interrupt vector table / trap handlers.

ETA next semester.

Could be an easy job for someone to do

1. Second timer - I was thinking of a count up timer, can be started stopped or paused through writes to a memory address.
2. Timer - Just gets the current time in number of seconds since midnight (12 hour format)

On loading different files the ones from the previous file will still appear

Menu options Run Tests and Rerun tests possibly don't work anymore due to the new calling convention checker.

Have index 0 in memory view be xFFFF, 1 be xFFFE, and so on.

The changed memory address does not appear in the the list of shown addresses

Currently links to /usr/share/complx-tools which does not exist, and is instead at /usr/local/share/complx-tools

seems to be a memory corruption issue. This is low priority since its not used.

I have a theme for Linux which does re skin the program properly, but I am running into a problem where the labels are the same color as be background and become unreadable. If you could add an option to change the text font or hard code the color for the background then the problem would be fixed.

Image with text labels being unreadable (nothing selected):

Image with text being selected to show the labels (text fields selected):

wxWidgets 3.0 was recently released (and probably not in ubuntu's repos yet) update the instructions to refer to 3.0 and not 2.9.

In one semester with Ubuntu 14.04 wxwidgets 3.0 should be in the repos.

workaround for now

sudo complx

for the first run, and then it doesn't hang anymore.

Requested in Fall 2014 feedback.

I think it should feature the following

1. Integration with complx
2. LC-3 flavoured syntax highlighting
3. Ability to set breakpoints in assembly code
4. Ability to see what line from .asm file is being executed in complx

A prototype can be found in the lc3edit folder. I originally was going to do this to get some experience with the wxScintilla widget, but if someone wants to do it then be my guest

This option will pop up a dialog asking user for following information

1. Subroutine to call
2. Parameters to subroutine
3. Stack location

The effects of this dialog are as follows:
The file is reloaded, Registers are randomized and Memory is randomized
PC = SUBROUTINE
The stack is loaded with parameters to subroutine

Essentially this is the same environment lc3test uses.
This is due for Fall 2015 semester.

It draws background in the label column.

Main memory view only tracks PC.

This could be useful for a memory view that shows the activation stack.

Seems as though the control buttons come up at inappropriate times.

For instance the buttons change to NO IO after some I/O from the console is consumed.

Does not seem to affect the output of the program, two characters disappear, but get read into R0.

Hey, I'm that guy from piazza, I know for class we're supposed to develop on linux, but for running it on my macbook on the go it'd be kinda handy.

Building complx on OSX just takes installing wxMac via homebrew and a tiny tweak to two of the makefiles's LDFLAGS (they use -soname, whereas clang supports -install_name). I think the install directory should be different too, but I just set PREFIX=./where/you/want/complx on the commandline for make.

If you're interested, I'll open a PR with the changes. I understand if you don't want to add another platform, but the changes are pretty minimal.

Basically just:
liblc3/Makefile:

UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Darwin)
    LDFLAGS := $(MASTER_CPP_FLAGS) -fPIC -Wall -shared -Wl,-install_name,$(OUTPUT) -L.
else
    LDFLAGS := $(MASTER_CPP_FLAGS) -fPIC -Wall -shared -Wl,-soname,$(OUTPUT) -L.
endif

lc3plugins/Makefile:

UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Darwin)
    LDFLAGS = $(MASTER_CPP_FLAGS) -fPIC -Wall -shared -L../liblc3 -Wl,-install_name,$@
else
    LDFLAGS = $(MASTER_CPP_FLAGS) -fPIC -Wall -shared -L../liblc3 -Wl,-soname,$@
endif

Running smoothly so far:

Redo all documentation files

Sometimes complx just crashes for no reason.

In its current state to check if the lc3 calling convention was followed one must check each individual address of things on the stack.

Should also handle the case where someone decided to store extra things onto the stack.

Activation Stack viewer was implemented as of summer's release.

ETA should have been this semester however I forgot.

This is actually two jobs.

1. A simple command line interface that just generates the test xml files.
   Design it however you want some ideas
2. You can read the .asm file and automatically determine what the input and output is via looking at the symbol table and then ask the user for test input and output values
3. Just ask the user several questions (like input symbol name, what is the type of it, etc) and then ask for test input output values
4. Integrating this in complx

To replicate, run the test XML below on working code. In the test report dialog, expand the root of the tree, and click the first child (labeled "MC91 (101)"). Error should occur before the frame is rendered.

Test XML:

<?xml version="1.0"?>
<test-suite>
    <!-- Test case you may have multiple of these --> 
    <test-case> 
        <name>mc91(101)</name>
        <!-- This flag determines if the test has a time limit in number of instructions default is 0 (false). Best practice is to always use this. --> 
        <has-max-executions>1</has-max-executions>
        <!-- The maximum number of instructions to run for.  Only works if the above flag for has-max-executions is 1 (true) --> 
        <max-executions>1000000</max-executions>
        <!-- Randomize memory before the test default is 0 (false)--> 
        <randomize>1</randomize>
        <!-- Specify the inputs to your assembly code here --> 
        <input>
        <!-- Parameter setting change N to be 101 -->
            <test-value><address>N</address><value>101</value></test-value>
            <!-- Prepare to call subroutine MC91 the following shall happen -->
            <!-- Set the Stack pointer R6 to xF000 -->
            <!-- Set the Return address R7 to x5000, A halt statement shall be placed here as well -->
            <!-- Set the Frame pointer R5 to be some value, after your code is finished running R5 better be the same value. -->
            <!-- Parameters will be loaded in the stack as specified in the calling convention and R6 shall point to the first parameter -->
            <test-subr><name>MC91</name><stack>xF000</stack><r7>x5000</r7><r5>xCAFE</r5><params>MEM[N]</params></test-subr>
        </input>
        <!-- Specify things you want to verify here -->
        <output>
            <!-- Answer is 91, no local variables-->
            <!-- The following checks are made -->
            <!-- R6 should be pointing at xEFFE (initial stack - num_params - 1) -->
            <!-- xEFFE must contain the answer 91 -->
            <!-- PC must be pointing at the return address specified above (x5000) -->
            <!-- R5 must contain the old frame pointer value specified above (xCAFE) -->
            <!-- Parameter 101 must not be modified and should still be located at xEFFF -->
            <!-- Return address x5000 should be located at xEFFD -->
            <!-- Old frame pointer xCAFE should be located at xEFFC -->
            <test-subr>
                <answer>91</answer>
                <!-- No local variables, so not including a locals tag -->
                <!-- Ignore this section unless you are a TA -->
                <points>
                    <answer>1</answer>
                    <params>1</params>
                    <r7>1</r7>
                    <r6>1</r6>
                    <r5>1</r5>
                    <locals>1</locals>
                </points>
                <deductions-per-mistake>1</deductions-per-mistake>
            </test-subr>
        </output>
    </test-case>
</test-suite>

Assertion details:

ASSERT INFO:
/usr/include/wx-3.0/wx/strvararg.h(456): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type

BACKTRACE:
[1] TestCaseInfoPanel::Update(lc3_test&)
[2] RunTestDialog::OnSelectTestItem(wxTreeEvent&)
[3] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[5] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[6] wxEvtHandler::TryHereOnly(wxEvent&)
[7] wxEvtHandler::ProcessEventLocally(wxEvent&)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[10] wxGenericTreeCtrl::DoSelectItem(wxTreeItemId const&, bool, bool)
[11] wxGenericTreeCtrl::OnMouse(wxMouseEvent&)
[12] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[13] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[14] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[15] wxEvtHandler::TryHereOnly(wxEvent&)
[16] wxEvtHandler::ProcessEventLocally(wxEvent&)
[17] wxEvtHandler::ProcessEvent(wxEvent&)
[18] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[19] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[20] g_closure_invoke
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_propagate_event
[24] gtk_main_do_event
[25] g_main_context_dispatch
[26] g_main_loop_run
[27] gtk_main
[28] wxGUIEventLoop::DoRun()
[29] wxEventLoopBase::Run()
[30] wxDialog::ShowModal()
[31] ComplxFrame::OnRunTests(wxCommandEvent&)
[32] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[33] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[34] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[35] wxEvtHandler::TryHereOnly(wxEvent&)
[36] wxEvtHandler::ProcessEventLocally(wxEvent&)
[37] wxEvtHandler::ProcessEvent(wxEvent&)
[38] wxWindowBase::TryAfter(wxEvent&)
[39] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[40] wxMenuBase::SendEvent(int, int)
[41] g_closure_invoke
[42] g_signal_emit_valist
[43] g_signal_emit
[44] g_main_context_dispatch
[45] g_main_loop_run
[46] gtk_main
[47] wxGUIEventLoop::DoRun()
[48] wxEventLoopBase::Run()
[49] wxAppConsoleBase::MainLoop()
[50] wxEntry(int&, wchar_t**)
[51] main
[52] __libc_start_main
[53] _start

Under windows the console does not seem to be writing any output.

The feature is hardly used, and with all of the changes since 2012 probably don't function anymore.

Repro steps:

1. Open Complx with any file open.
2. Double click on a NOP in the "Instruction Column"
3. Type "ADD R1," (this is how I found it, but it works for others too)
4. Observe that backspace does not delete characters.

-Matthew

I recall that blkw should not initialize the memory thats allocated and if Load Over or Randomized and load is used that memory should not be 0.

Possible bug?

If there are problems with a line then we should at least point out what part of the line is causing the error

example

ADD R0, R0, 105

105 overflows a signed 5 bit offset
ADD R0, R0, << 105 >>

1. The user should be able to specify a region of memory they are interested in viewing in the MemoryView
2. There should be a magic button (menu option) that removes all memory addresses containing 0 (This should take effect before randomization happens)
3. Another magic button (menu option) that removes all memory addresses not related to the program (this should happen on loading program). This will probably require magic hooks to be added in the assembler.

Leaving task as job for anyone reading who is interested, but if not resolved soon I'll just code this up myself.

Will help in people sending bug reports.

Plugins are broken as of version 4.6.0.0 probably due to the build system.

In about one semester most steps in the install script will be pointless and unnecessary since wxwidgets 3.0 should be available in official repos by then.