[HN Gopher] Terse: A language with hi-level look-and-feel, low-l...
___________________________________________________________________
Terse: A language with hi-level look-and-feel, low-level control
(1995) [pdf]
Author : sph
Score : 37 points
Date : 2024-01-12 10:17 UTC (2 days ago)
(HTM) web link (www.terse.com)
(TXT) w3m dump (www.terse.com)
| eterps wrote:
| I remember reading this in Dr. Dobb's Journal back in the day
| when I was still using Assembly language.
| CoastalCoder wrote:
| Dr. Dobb's Journal was a goldmine. I'm bummed that I discovered
| it so close to the end of its publication.
| sph wrote:
| Came across this while looking for simple languages close to the
| CPU, yet architecture independent? Sadly, seems like this one
| might be i386 specific.
|
| So, apart from Forth, any suggestion?
| eterps wrote:
| - simple language
|
| - close to the CPU
|
| - architecture independent
|
| These 3 aspects are insanely hard to combine effectively.
|
| Also is Forth 'close to the CPU'? It definitely is low-level.
| alexisread wrote:
| Yes, its used to bring up new hardware as its easy to write
| drivers for (See Open Firmware). If you look at
| https://github.com/dan4thewin/FreeForth2/blob/master/ff.asm
|
| You can see that the x86 registers are used to avoid SWAP
| instructions via register renaming. That's a sufficiently low
| level technique to qualify.
|
| The thing with Forth for me, is a lack of typing - you need
| to keep a model of the stack in your head at all times. It
| should be possible to build that in to a Forth compiler but
| I've yet to finish a prototype.
| sph wrote:
| I don't think that's insanely hard. If you squint hard
| enough, WASM has those 3 things as a goal, and it is
| conceptually much easier than developing a regular, general
| purpose language, say Rust.
|
| If you want to focus on performance as well (as WASM does),
| well, then it becomes really challenging to find a middle
| ground that works on IA64 and a 6502 chip.
|
| So I guess what I am looking for is WASM with less focus on
| performance and more on portability. Forth might be half a
| layer above the CPU, but is insanely portable and/or simple
| to implement from scratch, which is why I mentioned it.
| 5- wrote:
| there has recently been a revival of interest in simple c (or
| c-like) compilers, e.g.
|
| https://c9x.me/compile/ (c frontend:
| https://github.com/michaelforney/cproc)
|
| https://github.com/sysprog21/shecc (this fundamentally targets
| risc-like architectures, but is very clearly written).
|
| perhaps eventually a simple well-defined semantics will emerge
| (i think projects like the above already support more of a
| regehr-style c rather than iso).
| speps wrote:
| I always thought the ideas from the Mu project were
| interesting, not sure about its current status as I haven't
| seen Mu or Akkartik on HN for a while.
|
| https://github.com/akkartik/mu
| akkartik wrote:
| I'm around :) Mu is currently on the backburner in favor of
| my Freewheeling Apps built on LOVE
| (https://akkartik.name/freewheeling;
| https://news.ycombinator.com/item?id=36113115), particularly
| Lua Carousel (https://akkartik.itch.io/carousel;
| https://news.ycombinator.com/item?id=38397715).
|
| But I'm still open to jamming on Mu with somebody who knows
| more about OS development. Things like programming the PIC (h
| ttps://en.wikipedia.org/wiki/Programmable_interrupt_control..
| .) or testing against real hardware. For example, I'm kinda
| at an impasse with https://github.com/akkartik/mu/issues/52
| and would really appreciate some advice from an expert.
| sph wrote:
| Hi akkartik, I often come across your project as I think
| I'm on the same research path as yours, just trying from a
| slightly different approach. I am also interested in the
| bare metal/OSdev world for building a new language, as if
| you do it early you can avoid getting tainted with the
| semantics of the host OS you are working on (if you develop
| a language/OS combo on Linux, it'll probably end up looking
| very UNIXy)
|
| I haven't done OSdev in 20+ years
| (https://github.com/1player/klesh), but I hope I can set
| aside some time to dive into mu seriously and maybe pick
| your brain a bit :) keep up the good work!
| trealira wrote:
| C-- is like a lower-level, more primitive variant of C designed
| for code generation, hence its name. There aren't separate
| pointer types; everything is just bitsN, where N is the number
| of bits in the integer or pointer. Tail recursion is explicitly
| requested by writing "jump fn(args)".
|
| There's a computed goto, so you can build your own jumptables
| like this: section "data" { align 4; jump_tab:
| bits32[] { L1, L2, L3 }; } f (bits32 x) {
| goto bits32[jump_tab + 4*x] targets L1, L2, L3; L1:
| return (1); L2: return (2); L3: return (3);
| }
|
| This is a description of the language. I copied the above code
| from here.
|
| https://www.cs.tufts.edu/~nr/c--/extern/man2.pdf
| ksherlock wrote:
| You could write llvm assembly. It's somewhat architecture
| dependent in that registers have sizes and ABIs, etc.
| fasterik wrote:
| What about C89 or a similar subset of modern C?
| blacksqr wrote:
| Cool.
| anta40 wrote:
| Kinda reminded me to... Randall Hyde's HLA (High Level Assembly):
| https://www.plantation-productions.com/Webster/HighLevelAsm/...
|
| Looks like it isn't under active development anymore.
___________________________________________________________________
(page generated 2024-01-14 23:02 UTC)