why ?
- We already have an emit that does the same thing
- The name asm itself is a bit confusing, you might think it's an alias
for asm.js or something else.
- The asm keyword is used differently on different compiler targets (it
makes it inexpressive).
- Does anyone (other than some compiler libraries) use asm instead of
emit ? If yes, it's a bit strange to use asm somewhere and emit
somewhere. By making the asm keyword for js target deprecated, there
would be even less use of the asm keyword for js target, reducing the
amount of confusion.
- New users might accidentally use a non-universal approach via the asm
keyword instead of emit, and then when they learn about asm, try to
figure out what the differences are.
see https://forum.nim-lang.org/t/10821
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Per manual, `panics:on` affects _only_ `Defect`:s - thus `sysFatal`
should not redirect any other exceptions.
Also, when `sysFatal` is used in `nimPanics` mode, it should use regular
exception handling pipeline to ensure exception hooks are called
consistently for all raised defects.
At least on modern Nim `tempfiles` is not usable if the user has
https://github.com/oprypin/nim-random installed, because the compiler
picks the nimble path over the stdlib path (apparently).
Theoretical Benefits / Plans:
- Typed assembler-like language.
- Allows for a CPS transformation.
- Can replace the existing C backend by a new C backend.
- Can replace the VM.
- Can do more effective "not nil" checking and static array bounds
checking.
- Can be used instead of the DFA.
- Easily translatable to LLVM.
- Reasonably easy to produce native code from.
- Tiny memory consumption. No pointers, no cry.
**In very early stages of development.**
Todo:
- [x] Map Nim types to IR types.
- [ ] Map Nim AST to IR instructions:
- [x] Map bitsets to bitops.
- [ ] Implement string cases.
- [ ] Implement range and index checks.
- [x] Implement `default(T)` builtin.
- [x] Implement multi string concat.
- [ ] Write some analysis passes.
- [ ] Write a backend.
- [x] Integrate into the compilation pipeline.
- `copyFile` allows to specify `bufferSize` instead of hardcoded wrong
value. Tiny diff.
# Performance
- 1200% Performance improvement.
# Check it yourself
Execute:
```bash
for i in $(seq 0 10); do
bs=$((1024*2**$i))
printf "%7s Kb\t" $bs
timeout --foreground -sINT 2 dd bs=$bs if=/dev/zero of=/dev/null 2>&1 | sed -n 's/.* \([0-9.,]* [GM]B\/s\)/\1/p'
done
```
(This script can be ported to PowerShell for Windows I guess, it works
in Windows MinGW Bash anyways).
# Stats
- Hardcoded `8192` or `8000` Kb bufferSize gives `5` GB/s.
- Setting `262144` Kb bufferSize gives `65` GB/s (script suggestion).
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* make destructors accept non var parameters
* define nimAllowNonVarDestructor
* add a test case and a changelog
* update documentation and error messages
* deprecate destructors taking 'var T'
When parsing enums from strings using `genEnumCaseStmt`, `AnyEnumConv`
warnings are generated due to conversion from integer value. It seems
possible meanwhile to refer to the actual `enum` value by symbol instead
of being required to do the conversion from `ord`, even when the `enum`
is defined in a `block`.
* implements: [C++] constructor pragma improvement (fix#21921)
t
* fix test so it doesnt use echo in globals
* Update compiler/ccgtypes.nim
* Update lib/std/private/dragonbox.nim
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* test implicitly huge set types
refs https://github.com/nim-lang/RFCs/issues/298
* oh my god
* boot at least
* don't error, fix remaining issues, no 2 len arrays
* fix runnable example
* test assuming 0..255 for int literal
* test refactor, add changelog, test
