[libre-riscv-dev] offtopic: memory safety

[Luke Kenneth Casson Leighton]

On Thu, Jul 18, 2019 at 10:38 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Wed, Jul 17, 2019, 22:26 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Wed, Jul 17, 2019 at 10:41 PM Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > >  of even deeper concern is that they're used to justify one language
> > > > over another for completely inappropriate purposes.
> > > >
> > > yeah. though it is nice to have a programming language that is designed
> > to
> > > help you avoid UB, without needing extensive experience to get it right
> > --
> > > such as Rust (just don't use the unsafe kw), Python, Java, and others.
> >
> > agreed.  what will make me feel more comfortable about rust is when
> > (if) it stabilises enough for the gcc team to create a frontend for it
> > (like the fortran and java frontends, which some people aren't aware
> > these exist).
> >
> I thought gfortran (gcc's fortran frontend) was the canonical fortran
> compiler for linux? I'm somewhat disappointed that the java compiler was
> dropped due to not being maintained.

 ainooo... or, should i say "wheww" (java has to dieeee... :)

> > cutting out the llvm JIT intermediary and having the actual compiler
> > directly generate the assembler would alleviate some potential
> > security / safety concerns.  i'm much happier trusting something where
> > there's less "pieces in the puzzle" basically.
> >
> actually, rust is normally an ahead-of-time compiler -- I haven't heard of
> any JIT compiled modes yet,

 oh: i assumed that because it was using llvm, that JIT was the only
option.  iiinteresting...

> it can directly generate assembly, though it usually uses llvm's integrated
> assembler to output machine code directly -- just like clang.

 okaay.  that alleviates my concerns.

> also see https://github.com/thepowersgang/mrustc
> rust compiler written in C++ for code that is already known to have no
> compile errors -- translates to C -- currently mostly used for
> bootstrapping rustc

 ooOo.  that's very interesting, in its own right [the very first gnu
g++ compiler was also a c++ to c language translator]

> > i must have just totally lucked out with my choices of places to work
> > at.  the first one was CEDAR Audio (real-time audio restoration),
> > where they were doing TI (50MFLOP) DSP programming and had created
> > their own mixed c++ and x86 assembler GUI that ran on top of DOS, and
> > did its own INT33 handling, direct AT/XT bus assembly programming (to
> > communicate with the DSP card), wrote direct to the VGA screen and so
> > on.
> >
> neat!

 it's been 25 years: i often thought of getting in touch with them and
asking if they could release the source code.  the only reason they
did their own GUI / OS (on top of DOS) was because Win16/Win32 would
lock up the entire interrupt stack, totally useless for a real-time
application.

> > yyeah, they're an "interesting" company.  they can't do that - they
> > have to support their customers.
>
> that could still be done -- notice I said deprecate, not remove.

 oh, yeh.  missed that.

> >   there's even switches inside DOS
> > CMD.EXE which say "if executable == SIMCITY.EXE enable deliberate
> > malloc memory bug".
> >
> wow!

 ha, cool, it rally was sim city! https://news.ycombinator.com/item?id=2281932

 i thought i'd mis-remembered it

> I think they may drop some legacy support when intel drops mmx support
> (which I hear intel's planning on -- amd already dropped fp in mmx
> (3dnow!)), which has been replaced by sse2+ and avx since pentium 4 and
> amd64.

 yehhh if there's no hardware _left_ to run the legacy software, you
can be preeetty sure that anyone on that combination is never, ever
going to upgrade :)

l.