~lassipulkkinen

Finland

Recent activity

Re: [PATCH hare 1/4] rt: copy by words in memcpy a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

> > Also, this will break runtime array expansion, since harec abuses
> > memcpy for that.
> as of the state of the code in this patch, it doesn't break -- the end
> result of word-memcpy is identical to byte-memcpy for overlapping
> *aligned* regions:

Ah, you're probably right. However,

- Unaligned copies are rather common in I/O, etc, so doing those fast
  only 1/4 of the time is kind of lame. Most CPUs can do unaligned word
  copies just fine. Those cases will use memmove most of the time though,
  so I suppose memcpy could stay the way it is. :/ And if we intend to
  have arch-specific optimized memfuncs anyway, this can work fine as a
  lowest common denominator.

Re: [PATCH hare 1/4] rt: copy by words in memcpy a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

Also, this will break runtime array expansion, since harec abuses
memcpy for that.

Re: [PATCH hare 1/4] rt: copy by words in memcpy a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

> qbe does fold constant modulo operations. Unless you mean a variable
> modulo a constant? In which case & might make more sense, yeah.

Yes, that's what I meant.

$ harec - | qbe
export fn mod4(x: size) size = x % size(u32);

.file 1 "-"
.section ".text.mod4","ax"
mod4:
	pushq %rbp
	movq %rsp, %rbp
	movq %rdi, %rax

Re: [PATCH hare 1/4] rt: copy by words in memcpy a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

One thing to point out here: % by a constant currently isn't optimized
by harec or qbe in any way, so for small copies I'm sure the run time
will be dominated by the divs, and probably significantly worse than
before. Might make sense to swap those out for & unless we want to wait
for qbe to optimize this.

Re: [PATCH harec 00/10] Global variable improvements a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

> - check with two passes, first without type hints, emitting placeholders
>   where types aren't known, then with type hints determined by promoting
>   known operand types on each expression before recursing into the
>   operands, replacing the placeholders with concrete types. (this could
>   handle iconsts as well.)

A few corrections/clarifications:

- The promotion should probably be done in the first pass after
  traversing the operands, at least for arithmetic expressions.
- The promotion algorithm would have to be recursive, so [2]u8 and
  [2]u16 could be promoted even though assignability-wise they are
  mutually exclusive.
- If we want to keep the current integer type defaulting behavior

Re: [PATCH harec 00/10] Global variable improvements a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

> My main problem is the lack of tests. Every commit that makes changes to
> the language (i.e. non-implementation-details) should have tests to go
> alongside it. This would also make it easier to tell exactly what each
> commit is doing, when it's not clear at first from reading the commit
> message.

Agreed; I'll make a v2 once it's clear which parts will be merged.

> > [PATCH 03/10] eval: Forbid interpretation of integers as pointers:
> > i.e. equality comparisons and casts to uintptr. These weren't working
> > properly anyway, and, in many cases, can't:
> >
> > let x = 4;
> > let y = 8;

Re: [PATCH harec 00/10] Global variable improvements a month ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

> 1/10 seems reasonable besides the array hack, which i'm not a fan of,
> and i'm also not sure is correct (wouldn't it be triggered by
> [0, 0, 1]?)

Hmm, [0, 0, 1] seems to work fine. Elaborate?

> 2/10 (as well as the lower_implicit_cast patch and the expandable array
> overhaul) i'm not sure about.

I was expecting you to disagree on the refactor (which is why it isn't
included here), but what's wrong with 2/10? It's necessary to make
[0...] in globals properly O(1), and the problems I mentioned already
exist regardless. All it really does is make expandability casts eval to
array constants with less elements than their length, to avoid wasting

[PATCH harec] Link with libm 2 months ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

Signed-off-by: Lassi Pulkkinen <lassi@pulk.fi>
---
> ✗ #1018840 FAILED  harec/patches/freebsd.yml https://builds.sr.ht/~sircmpwn/job/1018840

Submitting as a separate patch since this should probably be done
regardless of the series. isinf() was already being used in typedef.c,
and signbit() is a macro too, so it seems the main reason this didn't
happen earlier is just luck.

 config.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.sh b/config.sh
index b30d662..1ef323b 100644
[message trimmed]

Re: [RFC PATCH harec 0/2] Expandable array refactor 2 months ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

Forgot to mention: this is to be applied on top of the previous patches.

[RFC PATCH harec 2/2] Remove array expandability from the type system 2 months ago

From Lassi Pulkkinen to ~sircmpwn/hare-dev

Fixes: https://todo.sr.ht/~sircmpwn/hare/782
Signed-off-by: Lassi Pulkkinen <lassi@pulk.fi>
---
 include/ast.h        |  4 ++
 include/expr.h       |  1 +
 include/type_store.h |  3 +-
 include/types.h      |  1 -
 src/check.c          | 87 ++++++++++++++++++--------------------------
 src/gen.c            | 58 +----------------------------
 src/parse.c          | 28 ++++++++++++--
 src/type_store.c     |  4 +-
 src/types.c          | 13 ++-----
 9 files changed, 73 insertions(+), 126 deletions(-)
[message trimmed]