Jump to content

Kaj de Vos

  • Content Count

  • Joined

  • Last visited

Community Reputation

101 Excellent


About Kaj de Vos

  • Rank
    Chopper Commander

Contact / Social Media

Recent Profile Visitors

386 profile views
  1. I don't know the specifics. I read it recently, going through a lot of history once more.
  2. It goes on. Jay Miner designed the Amiga chip set to be good at flight simulators.
  3. Fortunately, Meta can do this more elegantly. a + b ; Overflow trapped (in the future) overflow a + b ; May overflow Self-documenting, no comments needed. The same flow control is used for either returning a value or discarding it: c: either a = b [42] [0] This turned out to be surprisingly hard to generate C code for in all cases. I always thought of C as an orthogonal language supporting expression-based programming, but it isn't. The last example would be: c: to byte! a = b Not as terse as the C version, but more strongly typed.
  4. I always remembered the case in the classic "dragon book" on compiler development. Its central point is the complexity of compilers, and to illustrate that, they wrote about a compiler they knew that had only a few comments in the entire source, one of which read "This code is cursed!". I don't really feel that about my compiler. It's now my largest project, currently around 20,000 lines. For the first time in three decades it's beating my Atari emulator that was around 15,000 lines. A few central points of the machinery are fairly complex and tend to shift when small changes are made, but in general, the compiler is quite straightforward. It comes down to the right mix of using traditional compiler engineering insights and using much simpler REBOL techniques.
  5. To keep this the main thread, here is the announcement I just made in the parent forum:
  6. Previous post here I have launched the website for my programming language project. It is served by the language itself: https://language.meta.frl
  7. Lately, the discussion here has been showing signs of outgrowing this forum format, so I went ahead and made the website for the project:
  8. Previous post here I have created the website for my programming language project. It is served by the language itself (on Linux, not on Atari yet :- ): https://language.meta.frl I am collecting all the content there that we discussed here this year. Check back regularly for more.
  9. All agreed. My embedded story is from an Atari friend. He got a job at a company making embedded 6502 products. One of the products suddenly became too slow. He found that there was a multiplication in it, and a colleague had programmed it by adding the number to itself in a loop, and the multiplier had become larger. Oddly, in interpreted languages such as REBOL, ancient optimisation tricks such as replacing a multiplication with shifts are still relevant, because the interpreter doesn't do any optimisation on the code. In my language, this will be different.
  10. Carl Sassenrath first designed Amiga OS, and REBOL was initially just meant to be the language of the successor OS. So it is designed like an OS, or at least a platform, and should be able to do everything. The features didn't creep in afterwards, but were structured into an architecture. It was only many years later that the mainstream started publishing about the convergence of languages and platforms.
  11. Nice story. I think you're right. My similar story is that a house mate at university who studied mechanical engineering built a machine for his final assignment, but couldn't get it to work for a long time. Until one day he came home proud and told everyone he had finally gotten his control software to keep up with the machine, by replacing "float" with "int". I didn't know much about C, but it did stun me. I studied computer science myself, but over the years I started noticing a pattern that electrical engineers tend to produce much more practical software. They need it to control their actual interest, the electronics, but they view the software as a necessity that should just work, instead of expanding it until it can read email. They are also used to strict budgets on the electronics parts, so they develop their software the same. In our time on Atari, this was also still true for software engineers; we had strict budgets for program size and speed. These budgets have now gone out the window. They are replaced by budgets on complexity, bug count, runtime, power consumption, crunch time, death marches, missed deadlines, mid-project resets, network attack vectors and company defaults, but most people don't seem to mind much. REBOL is designed by an electronics engineer. Although it can read email. Oh well...
  12. Agreed, that's pretty much how I want to do it.
  13. True, but REBOL is superior there to Python, so not everything adds up. And if you want to run on 8-bits, or your customer and boss suddenly demand a faster application, you are stuck. Running a profiler also takes effort and time. I have never gotten around to it. I prefer to know myself where I can write better code. According to your definition, all current optimisations in my compiler are high-level. I only just got around to generating assembly code, so all current optimisations are done before that.
  14. Thanks for the links. The first one is about general program optimisation, which is done manually by the programmer, normally not by compilers. The second link is about all the optimisations VBCC does, high-level and low-level, but limited to C, the only source language it supports, which is a low-level language by todays standards. The documentation doesn't make much distinction between these optimisations, it mostly lists them. What I'm finding out is that some of these optimisations are hugely important, others not so much. VBCC and other compilers make them all optional. It doesn't make sense to me not to do the important optimisations, and about the lesser important ones I wonder whether they are worth the trouble. At least not now in the 6502 backend, and the C backend feeds into any optimising C compiler you want. Also, optimisations that are very important to do to the generated C code to make CC65 generate better code, several of which I learned from your essay, are seldomly or not at all mentioned in other compilers and documentation. Further, VBCC does quite a few optimisations with colourful names that are apparently standard in the industry, to turn bad code into good code. That is not my goal. I expect the programmer to turn in reasonable code, and then I will do my best to generate reasonable C or 6502 code. I wonder how much of the bloat in modern software arises because programmers are taught that they can write bad code and it doesn't matter - in some places and some circumstances, until it does. The third link is what we are looking for: a compiler trying to optimise code generated from high-level languages. It's specific to the Intel compiler, and it's very much focused on loop optimisations. This is an indication that there is apparently not much else that a lower-level backend compiler can do about code generated by frontends for high-level languages. Sorry, I don't have a link to similar thoughts about LLVM. I saw people state it in discussions on forums. In all this, there are a number of problems with wrong priorities, wrong timing and inflexibility, sometimes due to legacy architectures. High-level languages should do their own high-level optimisations when generating intermediate code for lower-level compiler backends, because only they know what their language is about. It's horribly inefficient for a backend to reverse engineer that on the fly, and usually simply not possible. But that's the mantra in the industry: we will allow you to write or generate bad code, and then our compiler will automagically fix it... REBOL is a flexible, but high-level language, yet it always struck me how much REBOL code might as well be written in, say, Action!. My compiler starts out by generating such low-level code, and will resort to more dynamic code in the future, only where it's needed. This makes all the difference: don't generate generic high-level code for a generic high-level virtual machine, make it fit the situation. An example are the loop optimisations I do. The loops are fairly abstract and high-level in the source code, but the compiler analyses them to produce loops that are specific to the situation. In turn, this allows CC65 to generate much better code for them.
  15. I designed it to be optimal for all kinds of optimisations. The data is abstracted through all stages, and I can add the metadata I need for an optimisation. The architecture is broadly similar to LLVM, although LLVM uses more traditional data formats. I am finding that I am doing optimisations differently than they are usually discussed. It seems that most optimising compilers generate unoptimised code and then run ever more optimiser stages over it. That seems backwards to me now. I optimise code as soon as possible. In recent years, LLVM has drawn criticism for not being able to optimise language-specific patterns. I suspect this is related. My ideas about optimisation are changing, so we should establish what we mean. What would you consider high-level optimisations?
  • Create New...