>>> Using this post as inspiration I replaced diffutils-mesboot with
>>> gash-utils-boot. diffutils-mesboot provided cmp and diff, both of
>>> which are available in gash-utils.
> It would be better if gash-utils worked with mes though. Now they all run in
> guile.
> In live-bootstrap project
2021 m. sausio 29 d., penktadienis 07:23:24 GMT Jan Nieuwenhuizen rašė:
> Efraim Flashner writes:
>
> Hi!
>
> > On Wed, Jan 20, 2021 at 03:19:49PM -0500, Timothy Sample wrote:
> >> Hi janneke,
> >>
> >> Jan Nieuwenhuizen writes:
> >>
> >> It looks like you’ve made a lot of progress on this
Efraim Flashner writes:
Hi!
> On Wed, Jan 20, 2021 at 03:19:49PM -0500, Timothy Sample wrote:
>> Hi janneke,
>>
>> Jan Nieuwenhuizen writes:
>>
>> It looks like you’ve made a lot of progress on this already (judging by
>> the rest of this thread). However, if it helps, the current Gash-Utils
>>> In effect, it seems there are now two diverging projects. I think that’s
>>> fine: more bootstrapping work and more diversity is better!
>> Converging actually as they share the exact same goal of bootstrap
>> from nothing and run MesCC
> My understanding is that they are nevertheless two
Hi,
"Orians, Jeremiah (DTMB)" skribis:
>> I see a fourth option, which is to keep both. :-)
> Might want to fix up the confusing naming in that case
Yes, that’s probably a good idea.
>> In effect, it seems there are now two diverging projects. I think that’s
>> fine: more bootstrapping
On Wed, Jan 20, 2021 at 03:19:49PM -0500, Timothy Sample wrote:
> Hi janneke,
>
> Jan Nieuwenhuizen writes:
>
> > I have reset Guix' wip-full-source-bootstrap branch with a first working
> > implementation of the, well, "Full Source Bootstrap" for x86-linux (and
> > x86_64-linux). This
> I see a fourth option, which is to keep both. :-)
Might want to fix up the confusing naming in that case
> In effect, it seems there are now two diverging projects. I think that’s
> fine: more bootstrapping work and more diversity is better!
Converging actually as they share the exact same
Hi,
jerem...@pdp10.guru skribis:
> 3) not actually converge the code and simply throw one or both of them
> away. Say write the whole thing in a better language than C (haskell
> perhaps but ultimately requires abandoning previous work).
I see a fourth option, which is to keep both. :-)
In
Hi janneke,
Jan Nieuwenhuizen writes:
> I have reset Guix' wip-full-source-bootstrap branch with a first working
> implementation of the, well, "Full Source Bootstrap" for x86-linux (and
> x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from
> the Stage0 project
>> I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2
>> branch)
>> is trying to achieve.
> Oh I see. It’s still kinda confusing to have two Mes. Wouldn’t it be
> nice to have just one?
yes it would.
Which is why a third scheme is being written in the Haskell subset
Hi!
Andrius Štikonas skribis:
> I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2
> branch)
> is trying to achieve.
Oh I see. It’s still kinda confusing to have two Mes. Wouldn’t it be
nice to have just one? I understand the goals are not exactly the same,
but is
Danny Milosavljevic writes:
Hi Danny,
> On Fri, 8 Jan 2021 19:56:19 +0100
> Danny Milosavljevic wrote:
>
>> The CI on nanana is currently building and running the tests.
>>
>> I'm curious what it will say.
>
> Tests succeeded.
>
> Pushed to mes on savannah as commit
Hi Janneke,
On Fri, 8 Jan 2021 19:56:19 +0100
Danny Milosavljevic wrote:
> The CI on nanana is currently building and running the tests.
>
> I'm curious what it will say.
Tests succeeded.
Pushed to mes on savannah as commit 10c38e112f177bc0b01ecf107d193e4c6b13
("wip" branch).
Hi Janneke,
On Fri, 08 Jan 2021 17:15:24 +0100
Jan Nieuwenhuizen wrote:
> > +/* TODO: On armhf gcc, max_align_t is 16 Byte big instead. Use that? */
> > +
> > +typedef double max_align_t;
> > +
> > #endif // ! SYSTEM_LIBC
>
> Is this something you can get more info on, or do we just try it
Danny Milosavljevic writes:
Hi Danny,
> I propose to, instead, change mes libc to align stuff malloc returns like
> this:
>
> That should fix it.
That's great; I'd like to go test this. Would you like to push to "wip"
when you're ready?
> diff --git a/include/stddef.h b/include/stddef.h
>
Danny Milosavljevic writes:
Hi Danny, Grishka!
> On Fri, 08 Jan 2021 08:16:29 +0100
> grischka wrote:
>
>> But no such thing happens in this case. The 'ptr' in init_putv()
>> comes from
>>
>> ptr = sec->data + c;
>>
>> and it seems that if tcc is doing the right thing then 'c'
On 2021-01-08 13:36:26 +, Orians, Jeremiah (DTMB) wrote:
> > If so, is libc malloc supposed to ensure alignment of allocated memory?
> > According to https://man7.org/linux/man-pages/man3/malloc.3.html yes.
> > @Janneke: So our mes libc malloc should be aligning the stuff--but it's not
> >
Hi Janneke,
I propose to, instead, change mes libc to align stuff malloc returns like this:
That should fix it.
diff --git a/include/stddef.h b/include/stddef.h
index a597c9bb..a682d726 100644
--- a/include/stddef.h
+++ b/include/stddef.h
@@ -37,6 +37,10 @@
#endif // !__MESC__
#endif //
Hi Janneke,
On Fri, 08 Jan 2021 07:25:52 +0100
Jan Nieuwenhuizen wrote:
> > Alignment could be disabled on the CPU
> >
> >
> > https://developer.arm.com/documentation/ddi0464/f/system-control/register-descriptions/system-control-register
> >
> > but I don't think EABI wants that.
>
> Hmm,
> If so, is libc malloc supposed to ensure alignment of allocated memory?
> According to https://man7.org/linux/man-pages/man3/malloc.3.html yes.
> @Janneke: So our mes libc malloc should be aligning the stuff--but it's not
> doing it. So it's a bug in our libc.
Looks like you'll have to waste
Hi grischka,
Hi Janneke,
On Fri, 08 Jan 2021 08:16:29 +0100
grischka wrote:
> But no such thing happens in this case. The 'ptr' in init_putv()
> comes from
>
> ptr = sec->data + c;
>
> and it seems that if tcc is doing the right thing then 'c' cannot
> be misaligned, and if
> Jan Nieuwenhuizen wrote:
Hello Arnold!
>> to the gawk-mesbot0 recipe also fixes "inc.awk". The pre
>> increment/decrement code looks like this:
>>
>> --8<---cut here---start->8---
>> *lhs = make_number(lval +
>>
Jan Nieuwenhuizen wrote:
> to the gawk-mesbot0 recipe also fixes "inc.awk". The pre
> increment/decrement code looks like this:
>
> --8<---cut here---start->8---
> *lhs = make_number(lval +
> (tree->type ==
Danny Milosavljevic wrote:
int main() {
double f = 1.0;
return 0;
}
...
I get a bus error here:
│ 0x24698 vstr d0, [r0]
│
...
And indeed, (0x24b01e % 8) == 6, not
Danny Milosavljevic writes:
Hello Danny,
> I just found the bug in tinycc that caused failed our ARM bootstrap to fail.
>
> I use the following reproducer:
>
> int main() {
> double f = 1.0;
> return 0;
> }
Beautiful! Well done! I can confirm that adding this patch
Dnia 2021-01-04, o godz. 18:01:21
Jan Nieuwenhuizen napisał(a):
> Hi!
>
> I have reset Guix' wip-full-source-bootstrap branch with a first
> working implementation of the, well, "Full Source Bootstrap" for
> x86-linux (and x86_64-linux). This bootstrap is rooted in the
> 357-byte hex0-seed
Hi Janneke,
I just found the bug in tinycc that caused failed our ARM bootstrap to fail.
I use the following reproducer:
int main() {
double f = 1.0;
return 0;
}
and then invoke
tcc a.c
on ARM (32) using your patched tcc. (but it's also broken in the unpatched tcc)
(tcc
Oops, g...@gitlab.com:janneke/tinycc.git in branch "mes-0.23"
pgpUsxbrGINDP.pgp
Description: OpenPGP digital signature
Paul Sherwood writes:
Hello Paul,
> On 2021-01-04 17:01, Jan Nieuwenhuizen wrote:
>> I have reset Guix' wip-full-source-bootstrap branch with a first
>> working
>> implementation of the, well, "Full Source Bootstrap" for x86-linux (and
>> x86_64-linux). This bootstrap is rooted in the 357-byte
2021 m. sausio 6 d., trečiadienis 11:32:48 GMT Ludovic Courtès rašė:
> Hi!
>
> Jan Nieuwenhuizen skribis:
>
> > I have reset Guix' wip-full-source-bootstrap branch with a first working
> > implementation of the, well, "Full Source Bootstrap" for x86-linux (and
> > x86_64-linux). This bootstrap
On 2021-01-04 17:01, Jan Nieuwenhuizen wrote:
I have reset Guix' wip-full-source-bootstrap branch with a first
working
implementation of the, well, "Full Source Bootstrap" for x86-linux (and
x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from
the Stage0 project
> I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2
> branch) is trying to achieve.
My fault for that confusion. Wish I was faster at implementing syntax-case in C
-_-
> Outside of Guix we are working on bootstrap that does not depend on guile
> driver and is driven
Hi!
Jan Nieuwenhuizen skribis:
> I have reset Guix' wip-full-source-bootstrap branch with a first working
> implementation of the, well, "Full Source Bootstrap" for x86-linux (and
> x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from
> the Stage0 project
Amazing work as always janneke.
We will just have to do some kaem work to make it work all on POSIX systems.
-Jeremiah
Hi!
I have reset Guix' wip-full-source-bootstrap branch with a first working
implementation of the, well, "Full Source Bootstrap" for x86-linux (and
x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from
the Stage0 project (https://savannah.gnu.org/projects/stage0):
35 matches
Mail list logo
