> 1. Re: Oberon Day 2011 Recordings (Jack Johnson)
> I have a few questions about your part of the keynote.
...
> Did you do your UTF-8 integration from scratch or did you look at
> other code for inspiration? Did it require extensive modification, or
> mainly just to Texts? What is your end goal for UTF-8 integration, and
> how do you see that ultimately affecting the simplicity of the system?
I added UTF string handling as an experiment (with a view to using it in
other projects), and tried various schemes, including UTF-16/UCS-2 and
even UTF-32 before finally settling on UTF-8. I didn't find much code for
inspiration, since most of what's available is in C ;-) but I was very
definitely inspired by the story of the invention of UTF-8 and its
integration into the Plan 9 from Bell Labs operating system.
UTF-32 is the only implementation where there is a linear mapping between
character length and byte length (UTF-16 has surrogate pairs, which breaks
that), but it is impractical on small systems because of the memory
footprint. UTF-8 performs well in practice, except for some Asian
locales, in which case an alternative encoding would be sensible (and
indeed advised by the Unicode documents).
Re-implementing Texts using UTF-8 is a really nice exercise (Luca?) :),
since the details of the Text system are so well explained in the book.
Certainly you would have to decide whether Files.Read would read a byte or
a UTF-8 char, and be careful about lengths and byte offsets. I had an
attempt, but ran out of time and will have to return to it [insert apology
to Fermat here]. For the Oberon System demo, it wasn't strictly necessary
so it didn't get in (along with a lot of other things I need to go back
and do properly).
> Are you using or have you considered using Oberon-07? How might that
> affect the rest of the original Oberon System code?
Yes it's all Oberon-07, I'm sorry if that wasn't clear. The main changes
were obvious: removal of SHORTINT, LOOP, and WITH, for example; and this
doesn't really change the text of the book that much, which is the aim.
> Have you had chats with Wirth or others about what they might have
> done differently if they could do it all over again?
:) I'm reminded that they asked Ken Thompson what he would change about
Unix, if he had the chance to go back and do it again. His answer was
that he would add an 'e' on the end of the 'creat' system call.
I once asked Prof. Wirth, after a retrospective lecture on Pascal, Modula
and Oberon, what he would do differently. He simply said he would have
called them Pascal, Pascal-2, etc.
> I noted the
> discussion of Objects in Appendix A of Project Oberon and aside from
> the Gadgets implementation it alludes to the idea that if the Objects
> module had existed at the outset it might have further simplified the
> original system.
This is Prof. Gutknecht's view, yes. Especially since the changes would
have been small, for the power it gives. But with power comes
responsibility, something we're not much good at in software IMNSHO. As
well as simplicity, and elegance, there should also be a clarity test.
That's why the book stands out.
> Did you consider resurrecting slim binaries, or does that add more
> complexity than it removes?
No, and yes. The slim binaries approach relies on the more complex OP2
compiler, with its high-level intermediate representation. I have no IR,
I basically just translate RISC instructions into x86 opcodes (if it's not
a RISC module, eg if it's a device driver). This adds a few hundred lines
at most to the compiler (for x86 and for ARM32 put together).
> Are the FPGA-based systems available?
Working on it. The compiler generates code which runs on the FPGA (as
does the Oberon-0 compiler, more-or-less unchanged, from Compiler
Construction). But more hardware needs to be implemented for the system
to be self-hosting, which is the aim.
Cheers,
Paul
