Re: New primitive types?

[Florian Weimer]

* Carter Schonwald:

> Which architectures are which?
>
> I assume you mean the dec alpha allowed atomic operations on bytes... but
> your phrasing is a teeny bit unclear

Early DEC Alpha had only word access.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Florian Weimer]

* Michal Terepeta:

> On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald 
> wrote:
>> One issue with packed fields is that on many architectures you can't
> quite do subword reads or
>> writes.  So it might not always be a win.
>
> Could you give any examples?

Historic DEC Alpha, now long obsolete.

It is very hard to create compliant and performant implementations of
Java 5, C 11 or C++ 11 on such architectures.  All these languages
(and their subsequent revisions) require that naturally aligned
objects can be accessed independently.  For example, you can't use a
simple read-modify-write cycle to implement a single-byte store using
word operations.

That's why such architectures really do not have a future (or even a
present), except maybe in niche markets such as GPGPU (but even there,
things are heading towards the de-facto standard memory model).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Do we have free bits in the info pointer itself?

[Florian Weimer]

* Ryan Newton:

> Our heap object header is one word -- an info table pointer
> .
>
> Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the
> object header for other purposes, right?

x86_64 has signed pointers, so the uppoer 16 bits are either all zero
or all ones.  Some systems use both, but it's rare on Linux.

Other 64-bit platforms use more bits.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Florian Weimer]

* Mikhail Glushenkov:

> Hi,
>
> On 9 August 2016 at 01:32, David Terei  wrote:
>> I imagine in Java, that I can construct an invalid pointer in foreign
>> code, and then cause segfaults without the Java code having any
>> issues. Just guessing at this, so very interested to know how it's
>> prevented if I can't.
>
> Yes, this can be done with JNI, see e.g. [1]. Additionally, by using
> sun.misc.Unsafe [2], one can cause segfaults even from pure Java.

You can also bring the JVM into an unstable state by triggering a
VirtualMachineError, basically an out-of-memory condition, a stack
overflow, or any other unrecoverable error.

You can also exhaust limited resources such as file descriptors pretty
easily.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

C-- specfication

[Florian Weimer]

I'm looking for a specification of C--.  I can't find it on the
cminuscminus.org web site, and it's also not included in the release
tarball.  Does anybody know where to get it?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: C-- specfication

[Florian Weimer]

* Yuras Shumovich:

 Are you interested in ghc's cmm? It is different from the original C--.
 (And it differs between ghc versions.)

Actually, I'm interested in some form of Mini-C (in the spirit of
Mini-ML or Featherweight Java) for some experiment, and I assumed that
people here would know where to get the C-- specification.  Looks like
I wasn't mistaken, thanks. :)

I'm not sure yet if C-- fits my needs, though.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

[PATCH] sync-all: Skip END actions on exceptions

[Florian Weimer]

The instructions at https://ghc.haskell.org/trac/ghc/wiki/Newcomers
were slightly outdated, and result in a rather confusing error
messsage:

$ ./sync-all --testsuite get
Unrecognised flag: --testsuite at ./sync-all line 872.
== Checking for old haddock repo
== Checking for old binary repo
== Checking for old mtl repo
== Checking for old Cabal repo
== Checking for old time from tarball

ATTENTION!

You have an old time package in your GHC tree!

Please remove it (e.g. rm -r libraries/time), and then run
./sync-all get to get the new repository.

== Checking for obsolete Git repo URL
$

The patch corrects the error message.  I've removed the --testsuite
flag from the wiki page as well.

From 1877358f8bd3fe47cc2035902d9c51351c79b443 Mon Sep 17 00:00:00 2001
From: Florian Weimer f...@deneb.enyo.de
Date: Thu, 13 Mar 2014 10:23:56 +0100
Subject: [PATCH] sync-all: Skip END actions on exceptions

Before this change, the END actions were executed even if the code
throws an exception using die.  This resulted in very confusing
error reporting when an invalid command line option was specified.
---
 sync-all |7 +++
 1 file changed, 7 insertions(+)

diff --git a/sync-all b/sync-all
index 4b4b7a3..70c9639 100755
--- a/sync-all
+++ b/sync-all
@@ -7,6 +7,7 @@ use English;
 $| = 1; # autoflush stdout after each print, to avoid output after die
 
 my $initial_working_directory;
+my $exit_via_die;
 
 my $defaultrepo;
 my @packages;
@@ -956,6 +957,11 @@ BEGIN {
 }
 $initial_working_directory = getcwd();
 
+$SIG{__DIE__} = sub {
+  die @_ if $^S;
+  $exit_via_die = 1;
+};
+
 #message == Checking for left-over testsuite/.git folder;
 if (-d testsuite/.git) {
 print EOF;
@@ -974,6 +980,7 @@ EOF
 }
 
 END {
+return if $exit_via_die;
 my $ec = $?;
 
 chdir($initial_working_directory);
-- 
1.7.10.4

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Why do we put GMP allocations on GHC heaps?

[Florian Weimer]

* Simon Marlow:

 We did originally look at targetting the mpn API, but decided against
 it for the reasons alluded to above - the mpz layer has quite a lot of
 stuff in it that you would need to replicate.  For instance, when you
 start doing an operation some calculation has to be done to figure out
 how much memory to allocate for the result.

Sure, and you have to do sign handling.  The advantage is that you
could use a convenient encoding for length and sign, or deal with
carry/borrow in a flexible manner (i.e., stealing another word from
the allocation buffer).  It's not exactly trivial, but the effort may
be worth it.

 And be extra careful, because the GMP code is GPL, so our
 replacement for the mpz bits would probably end up being GPL too.

Actually, it's LGPL, and interesting bits are part of libc under an
even more permissive license.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs