T1: Secure Programming for Embedded Systems [pdf] | Hacker News Reader

T1: Secure Programming for Embedded Systems [pdf]

t1lang.github.io

52 pointsjedisct124 comments

Pascal, Oberon and Ada were left out of the options, yet quite a few companies do their business selling tooling on this space. And regarding Java, there are other alternatives.

https://www.mikroe.com/mikropascal

http://www.astrobe.com/default.htm

http://www.microej.com/

https://www.aicas.com/cms/

https://www.ptc.com/en/products/developer-tools/perc

https://www.ptc.com/en/products/developer-tools/apexada

https://www.ghs.com/products/ada_optimizing_compilers.html

https://www.adacore.com/

I think the PDF link is a conference talk, so I'd guess that a more exhaustive review of options could be impractical in the time available.

One more reason for it to convein sound and relevant information.

A simple slide with an overview table would suffice, no need to deep dive into all of them.

Top level link: https://t1lang.github.io

Spec: https://t1lang.github.io/t1spec.pdf

Strange move to name a security focused embedded programming language the same thing as Apple's security processor in the 2016/2017 MacBook Pro.

https://appleinsider.com/articles/16/10/28/examined-the-new-...

Names are hard I guess. But if you're going to pick a [letter][number] name it'd be hard to come up with one that has a worse naming collision.

Apple's moved on to T2 in their current machines, so beyond "Isn't that Apple's old security chip?" questions it probably won't run into much overlap, but first thought was "is this Apple releasing something related to the T1 chip?"

The down votes are unjustified. I expected to see a guide on programming the T1 chip.

The previous version of the language was called “T0” and used for BearSSL. They were first, not Apple.

"T" beats it when you search for T0 programming language on google, so I don't think that was a good idea either.

As far as I can tell T0 doesn't exist anywhere online, unless I'm confused and it's actually this Scheme dialect from 1982 and T0 is a specific version number under that?

> There is no null pointer value. > • Reading from an uninitialized object field triggers a runtime error

How is this a better option? The side doesn't mention the alternative to null. Option types?

Also, what does a runtime error mean in this context? Restart of the whole application? Part of the application? Whole devices stops?

> Reading from an uninitialized object field triggers a runtime error

Can we catch errors? If so, then this isn't so much an issue.

How is that different than a null pointer exception will all it's downsides?

The slides indicated they were contemplating very small systems without an MMU or memory protection. Without those, a null pointer dereference may not be able to generate an exception.

Run time check, just like what happens here, I suppose.

I love the premise (seems suitable for non-embedded domains that currently use C!) but I can't get over the Forth-like / postfix syntax.

Personally I don't mind unusual syntax. I do find it a bit problematic that programming languages seem to select syntax almost at random, or at least they don't tend to spend a lot of time explaining it [0]. A lot of special characters can quickly become less pleasant with a non-English keyboard however. Especially if the syntax is hard to predict (with for example autocomplete).

[0] https://www.adacore.com/uploads_gems/Ada_Safe_and_Secure_Boo...

It seems strange to call out Ada for "unexplained" and "unusual" syntax. The syntax is very similar to the syntax of Pascal, which was an enormously popular language at the time when Ada was designed.

I meant that Ada does explain its syntax (at least partly in that pdf), but many languages don’t seem to. And when they do I can more easily accept whatever it is. It is when the syntax seems random I can’t wrap my head around it.

Ah, OK. It looked like you were citing Ada as an example of the problem, not of the solution.

I don't mind unusual syntax as long as it looks like C, so to speak. (C is weird, but I'm used to it, and context switching is easier the more similar a syntax is to C.)

Rust is described as having "lots of automatic magic". Not quite sure what they are describing.

I would consider the `Deref` trait as well as the liberal use of `Into` etc in libraries to fall under this category. Not _fully_ automatic, but generally not clear from the callsite (which, in the case of `Deref`, is the `.` operator).

How is Into magic? All it does is save some typing. It’s obvious at the point of use what it’s going to do. I agree that deref is slightly magical.

They want to promote their own language and wanted at least two reasons against Rust (the first with lack of LLVM support for many smaller embedded platforms is true).

To me Rust is much easier to understand than C++. But C is still more straightforward.

That kinda sounds like an endorsement for Rust. Or they couldn't come up with anything better.

Reply on news.ycombinator.com