
T1: A Modern Programming Language for Constrained Environments - kick
https://t1lang.github.io/
======
as-j
Ok, I know maybe it's too early in this projects lifecycle, but when I read
the page this was my initial reaction.

As an embedded engineer I found the github page incredibly frustration, and
it's tempting to just write it off. If the original author, or anyone else
putting a putting together a language page, here's question I shouldn't have
to dig for:

1\. Where's an example this has been used professionally? (or out side an
academic setting) I'm pretty risk adverse since FW/embedded systems are harder
to OTA, and changes once we've approved the HW design blows up projects. If it
hasn't been, be upfront about it.

2\. What's the plan for the project? Is the language stable? Is a standard
library next? I use a vendors language/BSP to avoid writing everything little
thing from scratch, like printf()

3\. Give me a comparison to other languages, why should I use T1 over any
other embedded solution. Include size, and maybe the performance hit.

4\. Show me some code. If I'm picking this for a project I need to think of
everyone else I need to teach the language too, and how they'll accept it. It
really helps for a quick glimpse at the syntax to see how foreign it is. Even
if it's just Hello World.

5\. How do I access peripherals/HW? For example if I need flash/nvram
persistent storage, access to the serial port am I back to C to write driver
or interface to the BSP? If so I now need good C skills, T1 skills and good
binding skills.

Thanks for everyone for the slides, reading the hacker comments pretty much
answered 1-5:

[https://t1lang.github.io/NorthSec-20190516.pdf](https://t1lang.github.io/NorthSec-20190516.pdf)

[https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/x509/asn1...](https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/x509/asn1.t0;hb=HEAD)

------
bluejekyll
Is this actively being developed? I don't see an update for the past 8 months.

From
[https://github.com/t1lang/t1lang.github.io/blob/master/North...](https://github.com/t1lang/t1lang.github.io/blob/master/NorthSec-20190516.pdf)
slides, are telling for the language analysis to see why they think it's
necessary to develop this:

Go:

    
    
      - Only with TinyGo*
      - Limited language/runtime support*
        - "support for goroutines and channels is weak"
      - Maps can ony have up to 8 (eight!) entries
      - GC: only for ARM, other platforms "will just allocate memory without ever freeing it" (but GC is required for proper string management)
    

Rust:

    
    
      - Inherits all memory-safety features of Rust
      - Heap is optional
        - But without the heap, everything is allocated on the stack
      - Supports ARM Cortex-M and Cortex-R, RISCV, and MSP430 (experimental)
        - Not other architectures that LLVM does not support
      - Typically more stack-hungry than C
      - Lots of automatic magic
    

Forth:

    
    
      - Many incompatible implementations
        - It's more a concept than a language (there is an ANSI standard)
      - You are support to "write your own Forth"
      - Very compact, with low RAM usage
      - Even less safe than C and not portable
    

Given all this, is it really cheaper to write a new language than add
architecture support to LLVM? I also don't understand the "lots of automatic
magic", is that referring to the generics and/or type inference in Rust?
Additionally, if not using Heap (the criticism about Heap being optional),
where else would you allocate memory besides the Stack? Can someone who does
embedded explain that?

btw, on the magic bit the T1 design does go on to talk about Generics support
and a rich type system.

Edit: this comment sounds too negative, and that wasn't really my intent. I
just wanted to better understand some of the considerations that were used in
deciding to make this new language.

~~~
snops
I'd be interested to see the comparison against zig[1], which I am eying up as
a quite interesting language for embedded development. I think the comparable
features would be:

\- No automatic magic, anything that looks like a function or memory
allocation is, anything that doesn't, isnt.

\- Good compile time code generation capabilities including reflection, much
nicer than C macros.

\- Runtime safety features, such as bounds checking, but not as intrusive as
Rust's borrow checker (which makes less sense for single threaded embedded
applications). These can be turned off in release builds.

\- Very good C interop for use with manufacturer HAL libraries etc, includes a
C compiler.

\- Better error handling than C, without needing full exceptions, instead the
"try" and "defer" macros nicely replace C's "goto" for error handling[2].

\- No garbage collection

\- Embedded is a first class target, unlike Go/TinyGo

\- Working async support on all platforms.

\- Sadly not as popular as others, one full time developer currently I think.

[1] [https://ziglang.org/](https://ziglang.org/) [2]
[https://eli.thegreenplace.net/2009/04/27/using-goto-for-
erro...](https://eli.thegreenplace.net/2009/04/27/using-goto-for-error-
handling-in-c)

~~~
mwcampbell
AFAIK Zig doesn't have a way to calculate maximum stack usage at build time.
But perhaps this could be done in a language-independent way, in LLVM. That
would probably be better anyway, since to really do it well, you'd have to do
whole-program analysis, including calls between Zig and C.

~~~
snops
Interesting, GCC has '-fstack-usage' to output the stack usage of each
function into .su files, I didn't realise LLVM was lacking this feature.

There is a tool in rust[1] I just found that makes LLVM emit this information
for rust code, but it stores it within[2] the .stack_sizes section in the
emitted .elf instead. Possibly a similar trick could be added to Zig

[1] [https://github.com/japaric/stack-sizes](https://github.com/japaric/stack-
sizes) [2] [https://llvm.org/docs/CodeGenerator.html#emitting-
function-s...](https://llvm.org/docs/CodeGenerator.html#emitting-function-
stack-size-information)

~~~
mwcampbell
I was referring to T1's ability to guarantee a particular stack size for the
whole program (if I understand correctly), not individual functions.

------
earenndil
> Everything here is provided under the MIT license. This means that you can
> use as you wish; you don’t have to credit me

Doesn't the MIT license require that it be reproduced with all derivative
works, including the copyright line (which includes the author)?

~~~
xeeeeeeeeeeenu
Yes, it does require that, even for binaries. MIT and [23]-clause BSD are
probably the most often violated FOSS licenses because most people aren't
aware of that.

BTW, that requirement is the reason why Boost, 1-clause BSD and 0BSD licenses
are a thing.

~~~
legulere
You can also use CC0 for software to dedicate something into the public
domain.

~~~
est31
In many countries, you can't release your works into the public domain. You
can only license them. Thus you should generally avoid CC0.

~~~
zokier
CC0 is explicitly designed with such legal issues in mind and includes a
license for legislations that do not have direct way of putting works to PD

> If the waiver isn’t effective for any reason, then CC0 acts as a license
> from the affirmer granting the public an unconditional, irrevocable, non
> exclusive, royalty free license to use the work for any purpose.

[https://wiki.creativecommons.org/wiki/CC0_FAQ#How_does_it_wo...](https://wiki.creativecommons.org/wiki/CC0_FAQ#How_does_it_work.3F)

[https://creativecommons.org/share-your-work/public-
domain/cc...](https://creativecommons.org/share-your-work/public-domain/cc0/)

~~~
est31
Alright thanks for pointing that out, I misremembered it then.

------
pdexter
For anyone looking for examples, there are some here
[https://github.com/t1lang/t1lang.github.io/blob/master/North...](https://github.com/t1lang/t1lang.github.io/blob/master/NorthSec-20190516.pdf)
.

------
speps
T0 mentioned there is already used and available there:
[https://bearssl.org/gitweb/?p=BearSSL;a=tree;f=T0;hb=HEAD](https://bearssl.org/gitweb/?p=BearSSL;a=tree;f=T0;hb=HEAD)

Example code:
[https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/x509/asn1...](https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/x509/asn1.t0;hb=HEAD)

The slides are also much more educative:
[https://t1lang.github.io/NorthSec-20190516.pdf](https://t1lang.github.io/NorthSec-20190516.pdf)

------
dewster
I would argue that a language targeting bare metal type applications should at
least be minimally aware of that underlying hardware. A single stack "virtual
machine" type language is generally a terrible fit for the 2 and 3 operand
register-based processors which dominate the landscape.

Every interview of Chuck Moore that I've read has contained zero push-back for
his rather wild claims. It's entirely possible for an industry to do go down
the wrong path for a while, but at some point, if Forth and stack processing
were the giant killers they were cracked up to be, you would see them enter
and dominate at least some portion of the mainstream. You can't say they
haven't been given enough time.

It seems there are many "Forth curious" programmers out there, but they aren't
being given the full picture with the various puff pieces and vanity projects
floating around that never really go anywhere. It's almost a culture of
victimhood.

~~~
throwaway17_17
I’d say calling a stack-based VM terrible is overstating the case a bit. In
[1] the number seem to bear out that converting from stack-based to register-
based yields an average, adjusted performance increase of approx. 25%. Also
the transition results in an increase of code size of approx. 45%. That speed
up is a non-trivial amount, but so is the code size increase, which is a valid
area of concern for embedded/resource constrained engineering. Also, while I
tend to STRONGLY agree about awareness of hardware at the language level
(although I don’t think this should be limited to just embedded environments)
the methods in [2] are automated and simple ways the Compiler can take stack-
based code and create optimized register-based instructions.

As an aside, there is probably a different argument to had about whether a
stack-based VM as the mental model of a language is beneficial, but as a said,
that is a vary different argument than discussing the technical ability to
transpire a stack-based VM to a register-based one.

[1] ‘Virtual Machine Showdown: Stack Versus Registers’. Ertl, Gregg, et al.
2005.
[https://www.usenix.org/legacy/events%2Fvee05%2Ffull_papers/p...](https://www.usenix.org/legacy/events%2Fvee05%2Ffull_papers/p153-yunhe.pdf)

[2] ‘Implementation of Stack-Based Languages on Register Machines‘. Ertl,
Dissertation. 1996.

~~~
dewster
I briefly skimmed [1] and their more sophisticated translation to a register
VM yielded a 25% increase in code size, and not the 45% you stated?
Regardless, VM to VM really isn't my point.

I still don't get the positives of why the programmer should be presented with
a stack machine SW model when there is no stack machine type stack to be found
in the HW. Programmers with no stack machine / language experience probably
think (as I did at one point): "the stack on my HP calculator stack works
great, why not base a language on that?" but it scales poorly, it gets really
hairy if the stack is the only place to store things, and it's a major
headache keeping the stack from going out of sync (hence Forth's clear I/O
comments regarding subroutine stack use).

~~~
throwaway17_17
You are correct about the 25%. That was a mistake (for anyone else looking,
the 45% was a decrease in the executed instruction amount from stack to
register.

Correction aside, I, at some level, agree with you. The question of
appropriateness/benefits of a SM model is different than considerations of the
effectiveness of the code. In terms of the Forth SM model and its explicitly
imperative model, I am familiar with the various
complaints/arguments/critiques for varying reasons. I certainly acknowledge
there is at least some burden placed due to the stack mechanics. I happen to
be particularly attracted to the approach and enjoy programming that way, but
that is just a preference of mine. However, I also tend to look at Forth as
imperative language with which to program in what Backus describes as
‘function level programming.’ I find the benefits as listed by Jon Purdy,
author of the Kitten language, in his talk about concatenative code to be
compelling enough that exploration and refinement of this idea space to be
valuable.

All that said, I am perfectly willing to consider that, as presented in Forth
and presumably in the proposed language, SM mechanics and models are a hurdle
for users of the language.

------
chubs
Sounds promising! I like the idea of open source projects being an
‘extraction’ from something mission-critical like BearSSL, similarly to Rails’
birth. Also agree totally re the comparisons of other languages, none are
really ideal for embedded. Although I suspect that embedded CPUs will simply
get more powerful for a given pricepoint, to the stage where we can use
basically any language eventually. I suspect the syntax might be too alien for
most though.

------
jupp0r
A code sample on the landing page would have been nice.

~~~
elcritch
These slides are handy:
[https://t1lang.github.io/NorthSec-20190516.pdf](https://t1lang.github.io/NorthSec-20190516.pdf)

------
tsegratis
From t1spec.pdf:

"Postfix source code can be readily serialized into an executable format
running on threaded code, a well-known code generation method that can allow
for a very small compiled code footprint"

What's that method?

~~~
rabidrat
You take each symbol in sequence and append a reference to the compilation
output. It's super easy and it results in a very small code footprint (it can
often be smaller than compiled C for equivalent code).

------
mwcampbell
For me the most interesting part of T1 is the ability to strongly guarantee
maximum stack usage, and the accompanying ban on general recursion. Are there
any other languages or compilers that do this?

~~~
zokier
Resource Aware ML is a research language which analyzes resource usage,
including memory bounds

[http://raml.co/](http://raml.co/)

------
rightbyte
It would be interesting to try this or Forth out in some serious embedded
system project. I wonder if I would get the "stack based" style to work in my
head.

------
heyflyguy
I'd love to see a statistic on the number of new languages announced on HN.

------
Galanwe
I don’t quite get the target of this language. The landing page says it should
be used for embedded systems, yet the compiler roadmap for v1 contains “
functions for reading and writing files”.

What files? This will run on top of an operating system? Why bother with a new
language then.

~~~
xondono
A lot of embedded systems use file storage even while not having an OS.

A very cheap way to add storage to low volume productions is to add a microSD
card. At that point it’s easier to go for something like FAT and work with
that

~~~
yc-kraln
and yet that sounds like a library and not a core language construct.

~~~
7thaccount
Some people like larger languages that have more of the basics rolled into
core. Not sure if that fits here though.

