read file data in bigger blocks, avoiding lots of file api calls
also removed crc step - seems easier to simply compare the bytes rather
than calculating two crc's
This introduces tyStatic and successfully bootstraps and handles
few simple test cases. Static params within macros are no longer
treated as PNimrodNodes - they are now equivalent to constants
of the designated type.
Lines from the original source are outputted as comments next to line directives.
Hopefully, this will make debugging codegen problems easier.
Other changes:
The frame setup code now uses a single-line C macro. My motivation was to reduce
the noise in the generated output and make it easier to step over the boiler-plate
code, but counter-intuitively this also improved the overall compilation speed a
little bit so I applied the same treatment to line tracking too (this reduces the size of
the generated files and the explanation is that probably the I/O overhead dominates
the macro expansion costs).
This patch greatly improves the "step over" operation available in debuggers.
In practice, there are often 4-8 lines of C code generated for each nimrod line
Each such line will be responsible to a single step in the debugger that is
a) not expected by the user
b) taking the user to an incorrect line in the nimrod code
To keep this working, all code generation should use the rope formatting
facilities when producing new lines (i.e. $n and $N).
New semantics for the format string are introduced:
$n means "soft new line" that could be joined/broken when lineDir is enabled.
$N means "hard new line" that will always appear as a new line.
As an alternative to this approach, I also tested producing code like this:
#line "code.nim" 154
foo = bar; \
foo(bar) \
This is better for readability of the final output, but unfortunately it didn't
produce the desired result across all compilers/debuggers.
