logicalshift

9 mesi fadiscuss

Had a look at my bookshelf to see what I could find that was obscure, maybe these would be interesting:

First Contract (Greg Costikyan) - a book about the economics of first contact

John Courtney Grimwood (author) - science fiction, generally cyberpunk, told from the point of view of characters who don't understand the tehcnology, which gives his work a kind of mystic vibe. (Eg, Nine-tail fox is about a detective trying to solve his own murder)

Footfall (Larry Niven/Jerry Pournelle) - was a big release back in the day, but not so well known these days. Hard SF alien invasion novel (Independence Day might have ripped this off a bit)

The NASA trilogy (Stephen Baxter) - dark alternative future books, with bleak endings but great science. I think not so well known these days because of the bleakness, but that's also part of what made them memorable when I read them.

logicalshift

3 anni fadiscuss

RISC OS is still available for the Raspberry Pi. You get to basic by pressing F12 and typing ‘BASIC’, and it has a built-in ARM assembler already - the manuals are all available online, there’s a BASIC manual and the Programmers Reference Manual for the whole OS.

(It’s exactly like a BBC B because this is the same version of BASIC, ported to ARM, it even emulates some of the hardware because back in the day they wanted to make software run without porting)

In theory typing ‘*CONFIGURE LANGUAGE 20’ (BASIC being module 20) should make it into a machine that boots straight to BASIC but when I tried it just now it just ignores the setting because the keyboard drivers aren’t loaded soon enough.

logicalshift

3 anni fadiscuss

I started off with a BBC Micro, followed by an Acorn A3000. My first 'PC' was a 486 card for the RISC PC - now there's an interesting architecture: the machine had two processor slots, but didn't require that the processors to have the same architecture. You could use the 486 as a very janky floating point accelerator for the ARM chip as well as to run DOS and Windows.

An interesting thing is that RISC OS is still available for the Raspberry Pi and it's a direct descendant from the operating system of the BBC Micro - not emulated. It still has the same level of direct hardware access, so if you ever wanted to use peek and poke (well, those are the ! and ? operators in BBC BASIC) on some modern graphics hardware, there's a way to do it. There's a built-in ARM assembler in there too.

What I think was really different about the time was the quality of the documentation. Nothing modern has the same sense of empathy for the user or achieves the same combination of conciseness and comprehensiveness. For instance, here's the BBC Micro's Advanced User Guide: https://stardot.org.uk/mirrors/www.bbcdocs.com/filebase/esse... (it's of particular historical note, because today's ARM architecture grew out of this system). You could build the entire computer from parts using just this 500 page manual, and you'll note that it's not actually a huge amount more complicated than Ben Eater's 6502 breadboard computer.

Weird thing: RISC OS actually has backwards compatibility with some of the old APIs so some of the stuff in the advanced user guide still works today on a Raspberry Pi (plus it comes with a BBC Micro emulator which was originally written because Acorn didn't want their new machine to fail due to a lack of software). These days there's also https://bbcmic.ro of course :-)

The Programmers Reference Manual for RISC OS is similarly well written, and surprisingly quite a lot of it is still relevant: most things still work on a Raspberry PI, and even modern operating systems still work pretty much the same way on the architecture. While things like MEMC, IOC and VIDC are long dead, there's a pretty direct lineage for the modern hardware to these older chips too.

logicalshift

3 anni fadiscuss

Alan Kay has done a few lectures about exactly this phenomenon: his talk 'Normal Considered Harmful' in particular is worth a look as it pretty much goes straight to the heart of the issue: https://www.youtube.com/watch?v=FvmTSpJU-Xc

logicalshift

3 anni fadiscuss

I wrote a parser generator quite a long time ago that I think improves the syntax quite a lot, and which has an interesting approach to generalisation: you can write conditions on the lookahead (which are just grammars that need to be matched in order to pick a given rule when a conflict needs to be resolved). This construct makes it much easier to write a grammar that matches how a language is designed.

Here's an ANSI-C parser, for example: https://github.com/Logicalshift/TameParse/blob/master/Exampl... - this is an interesting example because `(foo)(bar)` is fully ambiguous in ANSI C: it can be a cast or a function call depending on if `foo` is a type or a variable.

The new construct makes it possible to extend grammars and disambiguate them - here's a C99 grammar that extends the ANSI-C grammar: https://github.com/Logicalshift/TameParse/blob/master/Exampl....

It also allows matching at least some context-sensitive languages - see https://github.com/Logicalshift/TameParse/blob/master/Exampl...

An advantage over GLR or backtracking approaches is that this still detects ambiguities in the language so it's much easier to write a grammar that doesn't end up running in exponential time or space, plus when an ambiguity is resolved by the generalisation, which version is specified by the grammar and is not arbitrary (backtracking) or left until later (GLR).

I was working on improving error handling when I stopped work on this, but my approach here was not working out.

(This is a long-abandoned project of mine but the approach to ambiguities and the syntax seem like they're novel to me and were definitely an improvement over anything else I found at the time. The lexer language has a few neat features in it too)

logicalshift

4 anni fadiscuss

I've been working a 2D rendering toolkit that increasingly looks to me like it probably deserves a mention on these lists: https://github.com/logicalshift/flo_draw (but I'm not on Reddit...). Layers, vector sprites, dynamic textures and a streaming API that fits well with 'reactive' designs are amongst the features that make it stand out from what else is out there. It's super simple to get going too.

Started life as a rendering layer for FlowBetween so I could put in whatever looked like it was 'winning' later on but wound up writing my own renderer as there wasn't anything quite there yet. Still has that design so another unique thing is that it's possible to use the same API with whatever rendering layer you want.

Speaking of FlowBetween, one thing I have wanted to do for ages is to get rid of the platform-specific GUIs and use something universal. It should be easy because FlowBetween sends straightforward instructions to an independent GUI layer, but I keep bouncing off for a few reasons:

- it's a big ole task so I definitely want to pick something that's stable and also lets me hedge my bets in terms of being easy to migrate away from

- most commonly, FlowBetween needs pressure data from tablets and a lot of frameworks just don't do that (this is also in a terrible state in browsers)

- lots of GUI crates are designed as frameworks and so try to dictate the entire design of any app that uses them, which is no good for FlowBetween which tries to keep its internal design choices independent of its choice of GUI

At the moment, I suspect that some sort of imgui framework is best along with an entirely manual implementation of tablet pointer data: fits with my existing design and isn't 'contagious' in a way that could make it hard to migrate to something else later on.

logicalshift

4 anni fadiscuss

You didn't say which language you're using. If you're interested in Rust, I wrote a crate which deals with a bunch of bezier operations, including boolean path operations: https://docs.rs/flo_curves/latest/flo_curves/bezier/path/ind...

The 'better way' you're talking about here is the curve clipping algorithm, my version of which is here: https://docs.rs/flo_curves/latest/flo_curves/bezier/fn.curve...

Finding the intersections between individual curves is only the first part of this operation: you also need a way to determine which edges are on the outside of the new path (flo_curves uses raycasting for this, same operation that the OP focuses on, essentially) and deal with a fairly large pile of edge cases - literally edge cases here. Things like overlapping edges, nearly overlapping edges, what happens if a ray passes through an intersection point or directly across a straight edge, precision issues, curves with loops, etc.

logicalshift

4 anni fadiscuss

The main difference between the ARM1 (which was never sold in any quantity) and the ARM2 was the addition of the multiply instruction (and the multiply and accumulate instruction). They were the only multi-cycle arithmetic operation they had, and what's more you couldn't load arbitrary constants into a register with the MOV instruction or use constants with the multiply instruction itself so they were still a bit inconvenient as well as comparatively slow.

But you could write:

  MOV R1, #3
  MUL R0, R0, R1

In spite of the limitations, this gave the instruction set a certain 68000 quality to it (except much faster for a given clock speed).

To multiply the number in R0 by 3, which was pretty convenient. The ARM had a thing called the barrel shifter though, which let you add an arbitrary shift to the last operand of any arithmetic operation. All arithmetic ops take 1 processor cycle, so you could write this instead to multiply by 3 in a single cycle:

  ADD R0, R0, R0, LSL #1

Ie, add R0 to itself multiplied by 2. Constant divisions could be constructed with the SUB instruction too. Some constants required multiple instructions (but I think the maximum was something like 4 or 5 instructions for any constant? I wrote an assembler that could figure this out for you automatically in the mid-90s so I used to know for sure).

This is basically a single-instruction version of the 6502 trick (handy, because the first OS for the ARM was a hurried port of a 6502 operating system), which sort of fits with the ARM's original inspiration as being a 32-bit version of the 6502. As each instruction completes in one CPU cycle, the ARM could have fairly monstrous integer performance for the mid to late 80s if you knew how to program it.

comments