Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Is Systems Programming, Really?

willcrichton.net

Post reply on HN
Print view View original

21–30 of 93 posts

Re: What Is Systems Programming, Really?

#21

Post by josteink »

pjmlp wrote: post #19
josteink wrote: post #13

Earlier quoted context omitted.

> The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code. How is "val = PEEK adr" and "POKE adr, val" any less pol…

It shouts to you, "Take care something dangerous going on". Hieroglyphs are easy to pass by.

Lots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe.

    void DoSomeUnsafeStuffHere()
    {
        // regular code here. pointers verboten.
        
        unsafe
        {
             // pointery stuff here
        }
    }
I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.

Re: What Is Systems Programming, Really?

#22

Post by sigjuice »

tralarpa wrote: post #18
burfog wrote: post #12

A systems programming language can run on bare hardware by itself, or nearly so. It is acceptable to require a very small amount of assembly code, for example to implement something like memcpy or bcopy, or to provide atomic operations. A language is disqualified if it requires an OS or if it requires code written in a different non-assembly language. Cheating, by adding that as a huge (impractical) amount of assembl…

> It is acceptable to require a very small amount of assembly code, for example to implement something like memcpy or bcopy, or to provide atomic operations. There is some stuff missing in your list: preparing the stack pointer, address layout, etc. You also need tools to produce text and data sections that can be loaded at a specific address. Even if C is a low level language, there is still quite some stuff between…

stack pointer is an implementation detail. The standard does not mention the word stack even once.

Re: What Is Systems Programming, Really?

#23

Post by eterps »

josteink wrote: post #13
Athas wrote: post #10

Earlier quoted context omitted.

Pointers are not even necessary for writing operating systems or memory allocators. The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support so…

> The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code. How is "val = PEEK adr" and "POKE adr, val" any less pol…

It makes it easier to analyze code (i.e. greppable), and it allows for a distinction between operations that do direct memory modification and regular application code (pass by reference is accomplished with an entirely different syntax in Oberon, same for pointer types).

Re: What Is Systems Programming, Really?

#24

Post by eterps »

josteink wrote: post #21
pjmlp wrote: post #19

Earlier quoted context omitted.

It shouts to you, "Take care something dangerous going on". Hieroglyphs are easy to pass by.

Lots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe. void DoSomeUnsafeStuffHere() { // regular code here. pointers verboten. unsafe { // pointery stuff here } } I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.

What makes it unclear is exactly this 'pointery stuff'. There's nothing inherently unsafe about strongly typed pointers, but that's not the same as direct memory modification (which is obviously unsafe).

Re: What Is Systems Programming, Really?

#25

Post by m_mueller »

toolslive wrote: post #7

> You should be able to forge a number into a pointer, since that’s how hardware works. It's a C-centric view of the world and I wonder what old school FORTRAN77 people or lispers would think of this. Anyway, I think the right to do this should be a privilege of the compiler. As soon as you claim this right, you abandon all possible support she can give you in battling all kinds of silly mistakes.

As someone who likes Fortran90+ for numerics in HPC, I'd put it this way:

* Pointers are required mainly so you can do pointer swaps and be sure there is no unnecessary allocation (in simulations this often means being sure there's no 10-100GB allocation each timestep, which is where it really matters).

* Pointer math is unnecessary and only there because C has no/poor support of multidimensional arrays. Use a reasonable language like Julia or Fortran instead. In fact, the potential for pointer math has a big negative impact on performance since compilers have to assume aliasing. The __restrict solution is clunky in C and completely non-standard in C++, Fortran does not require this at all (no aliasing allowed except where explicitly stated).

* For almost all usecases (except swaps) a semi-managed approach like Fortran's allocatables or Objective-C's ARC or even retain/release seems to me the most straight-forward.

Re: What Is Systems Programming, Really?

#26

Post by saagarjha »

jillesvangurp wrote: post #9

System programming is definitely a bit overloaded these days though I believe it is now widely understood to be languages like C/C++ that can be used for OS, kernel, and embedded development. I would agree though that the language ecosystem is shifting a lot in the last few years. IMHO there are now a few languages that are becoming proper full stack languages in the sense that they scale from embedded all the way to…

> IMHO there are now a few languages that are becoming proper full stack languages in the sense that they scale from embedded all the way to browser development.

I think you're being a bit optimistic here: traditionally, the only language that has been able to do this is C++, and Rust is displacing it simply because Rust really tries to target C++ developers and their pains. But other than that I don't see much else development here. Swift has promise, but unfortunately nobody's really writing much framework or foundational code with it; at least not yet.

Re: What Is Systems Programming, Really?

#27

Post by saagarjha »

tralarpa wrote: post #18
burfog wrote: post #12

A systems programming language can run on bare hardware by itself, or nearly so. It is acceptable to require a very small amount of assembly code, for example to implement something like memcpy or bcopy, or to provide atomic operations. A language is disqualified if it requires an OS or if it requires code written in a different non-assembly language. Cheating, by adding that as a huge (impractical) amount of assembl…

> It is acceptable to require a very small amount of assembly code, for example to implement something like memcpy or bcopy, or to provide atomic operations. There is some stuff missing in your list: preparing the stack pointer, address layout, etc. You also need tools to produce text and data sections that can be loaded at a specific address. Even if C is a low level language, there is still quite some stuff between…

> You also need tools to produce text and data sections that can be loaded at a specific address.

Though, of course, most compilers provide extensions that make this task generally possible within C (using the loose definition of "I don't need any separate files or inline assembly, just attributes and flags).

Re: What Is Systems Programming, Really?

#28

Post by zaarn »

antirez wrote: post #6

My idea of system programming is that, other than the "near to the bare metal" element, which may not be always true, has this quality of creating infrastructures for other layers to use. A game 3D engine and a DNS server may be both written in C++ and may use the same low level programming techniques to achieve speed, but the fundamental difference is that one is just part of an application program of some type, and…

I think systems programming should be split in two, honestly.

You have the kernel-level systems programming where you need to be near the bare metal, where you write kernels or program microcontrollers with less RAM than a x86 CPU has L1 cache, where taking a microsecond longer can mean the overall system crashing (or even costing a human life).

And you have system-level systems programming where you write services and supportive infrastructure to enable user programs, where garbage collection and non-realtime behaviour is acceptable, where you can skip a microsecond and it'll be alright.

Re: What Is Systems Programming, Really?

#29

Post by v_lisivka »

chubot wrote: post #5

Hm I really like the observation that "systems programming" is overloaded. I gave my take here: https://lobste.rs/s/jrzwgy/what_is_systems_programming_reall... In short, I think shell is actually a more appropriate language for describing systems, rather than OCaml or Haskell! If that sounds weird, then I'll point you to the evidence of shell already being used for this purpose (e.g. the 40K lines of shell in the Kub…

It's simple:

Bugs in application code causes errors in that application.

Bugs in system code causes errors in an user application.

If bugs in your code causes problems only to your code - it's single application. If bugs in your code causes problems in other programs - it's system of programs.

Re: What Is Systems Programming, Really?

#30

Post by saagarjha »

m_mueller wrote: post #25
toolslive wrote: post #7

> You should be able to forge a number into a pointer, since that’s how hardware works. It's a C-centric view of the world and I wonder what old school FORTRAN77 people or lispers would think of this. Anyway, I think the right to do this should be a privilege of the compiler. As soon as you claim this right, you abandon all possible support she can give you in battling all kinds of silly mistakes.

As someone who likes Fortran90+ for numerics in HPC, I'd put it this way: * Pointers are required mainly so you can do pointer swaps and be sure there is no unnecessary allocation (in simulations this often means being sure there's no 10-100GB allocation each timestep, which is where it really matters). * Pointer math is unnecessary and only there because C has no/poor support of multidimensional arrays. Use a reason…

> Pointers are required mainly so you can do pointer swaps and be sure there is no unnecessary allocation

Many languages are getting around this issue by hiding pointers in their type system, performing copy-on-write, and taking the decision of whether allocations are performed on the stack or heap out of the hands of the programmer.

Post reply on HN