
LLVM Programmer’s Manual - adamnemecek
http://llvm.org/docs/ProgrammersManual.html
======
musha68k
I was just looking into LLVM the other day as I was researching the
possibilities of cross-compiling Rust to m68k on my Mac and now I simply can't
stop reading up on LLVM!

Support for Motorola 68000 has never been finished but this guy's abandoned
fork offers an interesting glimpse into how one might start going about it
though:

[https://github.com/kwaters/llvm-m68k/commits/m68k](https://github.com/kwaters/llvm-m68k/commits/m68k)

A bit over my head for now but I'm using this as a fun occasion to get back
into "proper" computer science. Dabbling is my favourite learning mode so
consulting the LLVM Programmer's Manual while hacking on a more isolated and
really simple task is something I'm very much looking forward to at this
point.

Still, if there is anybody with more knowledge who could chip in a bit on
supporting m68k or LLVM in general I'd be super curious to read about it :)

------
webkike
I believe that the heavy use of iterators in LLVM was a mistake. The ownership
mechanics has never not been a source of extreme confusion and annoying bugs.
But, it's still a great backend.

~~~
Joky
Can you elaborate? Especially I don't really see the relation between
"iterators" and "ownership".

~~~
slezyr
If you insert something in vector, then all iterators will became invalid.

~~~
Joky
Sure, but iterators have nothing to do with "ownership", so your point isn't
clear...

------
Rarebox
Notably, exceptions are not used. Instead errors are handled with assertions
and error objects.

~~~
adamnemecek
I feel like people are realizing that exceptions were a bad idea. They are
kind of like gotos.

~~~
IshKebab
Yeah finally. The problem with exceptions is that you lose context about where
the error occurred, and you really need to know that to handle the error
properly. That's why most exception handlers just print the error.

I think the only situation where exceptions help is in constructors, but there
are better solutions to that problem, like explicit object construction
methods that can return an error.

I think Go's approach to error handling is the best - explicit and in context.
Rust's `Result` looks quite nice though I haven' tried it yet.

~~~
co_dh
I don't agree neither :). Exceptions don't necessarily lost context. At least
in Python. In my previous job, whenever a python exception raise, the code
will catch it, with values of each variable, formatted in a beautiful html,
and send as an email. You can never overestimate how much time it has saved us
to debug. Go's approach to error handling remind me of the old COM days, while
you handle error after each function call. I'm glad it's no longer popular.

~~~
tkinom
Agree! I tried to move a program from Python to Go. Completely gave up on Go
after comparing two language's implementation on exception. Python is just so
much easier, cleaner.

Go's implementation on JSON parsing is also.....

------
jokoon
I wonder how hard it is for a coder with not a lot of knowledge about parsers
and LR/LL stuff to quickly define a language and translate it in LLIR.

That could be a fun thing to have a language competition that way, to see
which language "feels" good: easy to read, expressive, etc.

~~~
davorb
Assuming that you are somewhat familiar with assembly programming and know how
to produce a syntax tree, getting it to output compilable LLVM IR should take
you at most a couple of days.

------
vbit
Do LLVM have any support for coroutines?

If I wanted to implement a language with Lua-style coroutines, could I target
LLVM?

~~~
Others
Unfortunately, I don't think it does currently. I think you'd have to
reimplement them yourself on top of LLVM... That might change though, this co-
routine proposal just came up on the mailing list:
[https://github.com/GorNishanov/llvm/blob/coro-
rfc/docs/Corou...](https://github.com/GorNishanov/llvm/blob/coro-
rfc/docs/Coroutines.rst)

