| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* this resulted in assertions (crashes!) for harmless typos like "+23="
* a test case has been added
|
|
|
|
optimizationa and additional checks
* undo tokens emitted by the expression stack no longer waste
memory by pointing to the stack implementation.
This uses some ugly C++ constant template arguments but
saves 4 or 8 byte per undo token depending on the architecture.
* Round braces are counted now and the return command $$ will
use this information to discard all non-relevant brace levels.
* It is an error to close a brace when none have been opened.
* The bracing rules are still very liberal, allowing you to
close braces in macros belonging to a higher call frame
or leave them open at the end of a macro.
While this is technically possible, it is perhaps a good
idea to stricten these rules in some future release.
* Loops no longer (ab)use the expression stack to store
program counters and loop counters.
This removes flow control from the responsibility of the
expression stack which is much safer now since we can control
where we jump to.
This also eased implemented proper semantics for $$.
* It is an error to leave loops open at the end of a macro
or trying to close a loop opened in the caller of the macro.
Similarily it is only possible to close a loop from the
current invocation frame.
This means it is now impossible to accidentally jump to invalid
PCs.
* Even though loop context stacks could be attached directly to
the macro invocation frame, this would be inefficient.
Instead there's a loop frame pointer now that is part of the
invocation frame. All frames will reuse the same stack structure.
* Loops are automatically discarded when returning using $$.
* Special aggregating forms of the loop start (":<") and loop
end (":>") commands are possible now and have been implemented.
This improves SciTECO's capability as a stack-oriented language.
It is no longer necessary to write recursive macros to generate
stack values of arbitrary length dynamically or to process them.
* All expression and loop stacks are still fixed-size.
It may be a good idea to implement dynamic resizing (TODO).
* Added some G_UNLIKELYs to Execute::macro(). Should improve
the branch prediction of modern CPUs.
* Local Q-Register tables are allocated on the stack now instead
of on the heap (the bulk of a table is stored on the heap anyway).
Should improve performance of macro invocations.
* Document that "F<" will jump to the beginning of the macro
if there is no loop.
This is not in standard TECO, but I consider it a useful feature.
|
|
|
|
* use small values for low precedence
|
|
* SciTECO now has the same operator precedence table as C.
* It is numerically important whether different operators
have the same precedence. E.g. "5*2/4" used to be evaluated
by SciTECO as "5*(2/4)" since division had a higher precedence
than multiplication. Within in real (!) numbers this would
be the expected evaluation order.
Users of other programming languages however would expect
the expression to be evaluated as "(5*2)/4" which makes
a numerical difference when working with integers.
* Operator precedence has been implemented by encoding it
into the enumeration values used to represent different
operators.
Calculating the precedence of a given operator can then
be done very efficiently and elegantly (in our case using
a plain right shift operation).
* documentation updated. We use a precedence table now.
|
|
expression stack
this was probably a regression from d94b18819ad4ee3237c46ad43a962d0121f0c3fe
and should not be in v0.5.
The return value of Expressions::find_op() must always be checked since
it might not find the operator, returning 0 (it used to be 0).
A zero index pointed to uninitialized memory - in the worst case it
pointed to invalid memory resulting in segfaults.
Too large indices were also not handled.
This was probably responsible for recent PPA build issues.
Valgrind/memcheck reports this error but I misread it as a bogus warning.
I took the opportunity to clean up the ValueStack implementation and
made it more robust by adding a few assertions.
ValueStacks now grow from large to small addresses (like stack data
structures usually do).
This means, there is no need to work with negative indices into the
stack pointer.
To reduce the potential for invalid stack accesses, stack indices are
now unsigned and have origin 0. Previously, all indices < 1 were
faulty but weren't checked.
Also, I added some minor optimizations.
|
|
warnings
* Clang++ does not see that the PC will never go beyong g_assert(false),
and so reports about possible unitialized variables
|
|
|
|
also changed precedence of + operator (higher than minus).
the effects of this should be minimal
|
|
this fixes the "\" command and ^E\ string building characters
|
|
* the GError expection has been renamed to GlibError, to avoid
nameclashes when working from the SciTECO namespace
|
|
normally, since SciTECO is not a library, this is not strictly
necessary since every library should use proper name prefixes
or namespaces for all global declarations to avoid name clashes.
However
* you cannot always rely on that
* Scintilla does violate the practice of using prefixes or namespaces.
The public APIs are OK, but it does define global functions/methods,
e.g. for "Document" that clashed with SciTECO's "TECODocument" class at
link-time.
Scintilla can put its definitions in a namespace, but this feature
cannot be easily enabled without patching Scintilla.
* a "SciTECO" namespace will be necessary if "SciTECO" is ever to be
turned into a library. Even if this library will have only a C-linkage
API, it must ensure it doesn't clutter the global namespace.
So the old "TECODocument" class was renamed back to "Document"
(SciTECO::Document).
|
|
instead throw an error. The error could theoretically be thrown
earlier instead of only when trying to perform a calculation.
test cases: "++", "+1+", etc.
|
|
test case: 1<()>
* an empty brace (or content that does not leave anything on the stack)
resulted in the brace op to be left on the stack which makes the op stack
inconsistent
|
|
|
|
* C++ runtime does not automatically throw an exception
|
|
* new Expressions::format()
* may be used format numbers as part of arrays (Q-Register names)
|
|
* storage size should always be 64 (gint64) to aid macro portability
* however, for performance reasons users compiling from source might
explicitly compile with 32 bit integers
|
|
|
|
|
|
|
|
|
