uart_isr, when applicable, will reset CSR_UART_STAT after it has written new data to the UART module. If the UART module is able to finish that request before uart_isr writes to CSR_UART_STAT, then uart_isr will end up clearing the wrong event. This prevents uart_isr from ever being called again, and stalls all outgoing data
Just a slight fix. Don't like non-distribution stuff to populate /usr/bin cheers, David
Run with ./fpvm mod.fpvm Or, more entertaining ./fpvm -x mod.fpvm For every last gory detail, use ./fpvm -d -x mod.fpvm
This engine also accepts symbolic register names. Uses pfpu for stepwise execution.
This patch contains the following changes: - new option -v for verbose operation. By default, pfpu now only displays the result line and ignores the rest of the session. - send nc's diagnostics to standard output so that we can suppress its "connected" line (alas, this means that error messages are only shown in verbose mode) - added header comment
A number of small improvements: - VECTOUT doesn't need a destination register (use 0) - QUAKE is unary, not binary - option -a to automatically fill the latency slots with NOP (without caring about efficiency) - all registers referenced (read or write) are listed
The option -i wasn't shifted off, causing pfpuasm and ultimately cpp to fail.
… result The environment variable M1_HOST defines on which M1 to execute the code. M1_USER and M1_PW define the telnet access.
We can substitute !X it with X == 0. This catches cases where boolean not is used algorithmically and not directly with if.
This has ripple effects all through libfpvm but shouldn't change functionality.
We provide a function node_is_op for the library user to make this distiction as well (used in parser_helper.c). Note that this change means that we can't report the name of the operator that causes an "Operation not supported" error. This is visible to users in the case of op_not. Fix later.
We'll soon use "not", and this would get confusing.
A small bit of cleanup, to allow Flickernoise to do the same. - Werner
This warning was generated when compiling x86-linux/, which uses clang instead of gcc.
They still contained lots of old junk.
Only one minor conflict found.
The math functions have too many issues to make this viable without substantially more fixing. Just fix what little else is there.
And fix resulting warnings.