λ - programming

i was just looking information on this topic
im just learning about low level programming and i need some books or a basis to start
some lainer help me

>>6264
also what is the programming language in the pic

>>6268
Looks like LogiSim or something similar, it's just a circuit simulation program.

Can't help with the books m8, the one I read was written by the teacher of my class and they change a lot depending on the processor.

>>6268
I forgot to put that in the OP. We should collect resources on this subject as well.

I'd recommend that you read this first:
http://www.charlespetzold.com/code/

I've been writing some ARM assembly for an embedded micro lately (LPC 13xx). I find it quite refreshing, actually. The goal of the software if quite simple so it's not a case of me getting in over my head, and being able to control every instruction does make for a very straightforward work flow.

>>6268
A great place to start would be the book "The Art of Assembly Language" by Randall Hyde. It's a really solid book and has everything you need to know for getting started with assembly.

http://www.plantation-productions.com/Webster/

It seems like all embedded programming is done in C and asm. Id like to try embedded programming with something like Fortran. I dont think you need pointers to do systems programming.

>>6264
Man I had no clue Logism could be that powerful. All I've ever done was a basic ALU…

>>6330
I've heard some bad things about this book—mostly that it focuses way too much on HLA.

>>6268
Programming from the Ground Up is a free book teaching assembly on GNU/Linux:
https://savannah.nongnu.org/projects/pgubook/

> also what is the programming language in the pic
It's a 4 bit microprocessor made by someone on /g/ using LogiSim:
https://rbt.asia/g/thread/36690350#p36699284

>>6264
Tried making something in Logisim a while ago with reversible logic stuff, but somehow forgot how to get tot he combinatorial analysis window or something and wasn't able to readily turn my lower level parts into something less memory-intensive. Might get back to that later, but I'd have to either start over or get it off my old computer.

Much more recently, started trying to learn Pure Data, which is made to work much like audio patch systems and thus could probably have its patches implemented in a low-level manner. Reversible logic might work out nicely here too, but what I'd really like to try here is see if I can use it for neural networks.

How low do you want to go?
Computer made from dominos!

I know not a langueage but its nice stuff and thought you guys might appriciate it!
(ok so no ram and can only do single calculation every setup... but its very cool)

https://www.youtube.com/watch?v=OpLU__bhu2w&feature=youtu.be

The indervidual making of and/or/xor gates:
https://www.youtube.com/watch?v=lNuPy-r1GuQ

>>8191
if we are talking about gamey things, on >>>/rpg/1983 there is a thread about TIS-1000. It's a game about programming a strange computer with multiple CPUs in assembly. It's pretty good, even if it's not the real thing.

>>6264
check the books from these two guys, they have really great books, and if you like to program in that border between hardware and software

People who liked this thread also liked: nand2tetris.org

I enjoy a distributed virtual processing environment with other low level hackers here: skullcode.com
Such anarchy is too chaotic for most, even among machine level coders, but its exciting to know one mistake and my subprocess can be exploited. Frequent snapshots makes getting cracked fun instead of painful.

Limiting oneself to existing architectures is not progressive, IMO. For instance, on most processors the instruction pointer is protected -- you can only modify it via opcodes, directly writing to it can corrupt the execution flow. Skullcode's machine takes this a step further and has a separate call stack for return instruction pointers. Only root level (ring 0) code can manipulate the call stack directly, user code can only affect it via opcodes (eg: call / ret). Separate code and data stacks eliminates all stack smashing exploits. There is nothing a function can do to modify the caller's stack reference frame since the return operation always restores the parameter base pointer to its prior value (along with the instruction pointer).

On the skullcode machine stacks grow UP rather than down. Since the stack grows UP the size allowed for that function is not limited to how much it was allocated upon call, there's no need for a special "variadic" distinction, as all functions can take as many parameters as there is remaining system memory. Upon stack overflow the kernel can grow a program's stack and/or relocate it. Since data is accessed by offset from its base "segment" pointer this means you don't have to go trace down and modify every "pointer" to grow the stack. This also makes language level G.C. implementations insanely fast (and largely unnecessary). No more need to implement recursion on the heap. Note: calling heap based recursion "iteration" is wrong, IMO. One has just implemented a separate stack for parameter data which grows UP instead of down, which should have existed all along...

In other words: Study the existing chipsets, yes, but just remember that they are not the be all end all to chipset design. E.g. stack smashing exploits needn’t have existed after modern ARM or 64 bit chipsets came out, but the hardware designs embrace old programming techniques. Any OS that implements stacks differently than hardware intends suffers performance penalties due to moronic hardware design decisions.

>>8539
Would you link me to some reading material concerning skullcode? I would be very grateful.

>Study the existing chipsets, yes, but just remember that they are not the be all end all to chipset design.
I completely agree with this. Modern machines and the systems built on them are based on so much backwards compatibility and mistakes. It's nice to see new and innovative machines.

Every assembler I look at is the same thing, complexity and backwards compatibility. The only solution I've found is to start thinking about what I want in an assembler and to make that a reality.

>>8545
What about something like RISC-V? It's not backwards compatible with anything, by design. At least not yet.

>>6264
>You can't be good at anything without an understanding of what that thing actually is.
Hardware is a different thing from software.

I do think hardware is hella cool, I'm just sick of the pretentiousness of hardware fanatics. Hell, why stop at hardware, why not go down to the level of quarks, or lower?

>>8546
The thing about RISC-V is that it's RISC.

It's designed to be used by compilers instead of people.

I wrote a post in /tech/ that goes into more detail about my opinions on this:
>>>/tech/9154

I feel attracted to this metal level programming, but the whole Electronics world is totally alien to me, and I haven't yet the patience to start reading a good book on the subject.
Anyway, I wanted to share this with me fellow lains, it's the book I want to read after I get the ground basics
I hope you like it
[code]
Build your own Z80 Computer
[/spoiler]

>>8191
>>8191
This is some awesome soykaf. Much appreciated anon.
I'm going to actually try the binary adder, not with dominoes but with WireWorld
http://www.quinapalus.com/wi-index.html

>>8696
>Build your own Z80 Computer
Have you tried reading CODE The Hidden Language of Computer Hardware and Software.Its basically starting from basic gates to building a full blown computer.

>>9629
sounds a bit like "the elements of computing systems"

https://www.coursera.org/course/nand2tetris1

Anybody writing Go/Rust? Latest Go release has pauseless garbage collection + Rust is a joy to write

mfw thats muh gif

I'm taking a class that is introducing VHDL. Does that count?

>>9645
Wrong thread?
Serioulsy, this is like, opposite to what this thread is about.

>>9786

Very much so, not only does it teach you about building a processor from scratch, but also on how to deal with signals down to the delta cycle.

It really hits the spot of OPs statement:
>What I prize most about all of this is how you gain a real understanding of what modern computation is from it all.

Ultimately it's just a blueprint for an ASIC, can't get any more bare metal than that.

I'll begin: What standard is currently taught in classes? '93 was the one I learned, maybe now they will introduce the some newer features. C++0x would be a prime example for such things.

On a related note, I wish everyone would hurry up and catch up with VHDL-2008 because those generic types are rather useful.
Of course that will take at least 5-10 years at this rate, like every other common language in the field tried and true is king.

>So many people program who don't know how these things actually work. You can't be good at anything without an understanding of what that thing actually is.

The essence of computing has nothing to do with the physical hardware we use to do our computations. Learning about assembly languages and digital circuits is interesting in its own way, but the above logic is very flawed.

>>9800
>The essence of computing has nothing to do with the physical hardware we use to do our computations.
True, for the most part.

>Learning about assembly languages and digital circuits is interesting in its own way, but the above logic is very flawed.
It is perfectly sound in a world where abstractions regularly break.

The lowest level accessible in a computer system, the bedrock abstraction, will be what users need to understand, because what is above that will be broken or circumvented for various reasons. As it stands, the overwhelming majority of computer systems don't have very high-level bedrock abstraction.

It would be nice if the majority of computer systems were only programmable in an more abstracted language, but the market overlords have decided that isn't what we need.

>>6290
Computer Engineer here, can confirm Petzold's book is an excellent introduction to the field

>>10354
Sophomore CS student here. I'm reading it because I've heard great things about it, and I'm in love with the style. Very easy to understand without sacrificing much in the way of complexity.

>>9801
One idea that's been bouncing around my head is to make an OS that is essentially a lisp interpreter. Maybe it could use the linux kernel, maybe not, but I'd want everything to be a) abstracted away from real hardware and b) reliable.

It might also be a cool idea to strip it down even more and make an OS with no kernel, just a lisp interpreter and some barebones hardware virtualization. You'd need a pretty robust lisp dialect(racket comes to mind) but it would be a cool idea for a research OS.

>>10364
Are you me?
Maybe we couldvwork together, what do you say?
Pls respond

>>10364
>>10368
I started building a mock lisp OS yesterday.
>neurosuggesting I'm not being spied on by kalyx's brigade of cyber warriors so they can pretend to have the same interests as me

>>10368
sure, if I find the time. Tox?

>>10370
"mock"?

>>10374
I'm not him, but he didn't mean a mock lisp. He probably meant Mocklisp, which was the programming language of Gosling Emacs.

Grep this page for 'mocklisp' and you'll be able to read more:
https://www.gnu.org/gnu/rms-lisp.html

>>10381
interdasting.

>>10364
Ive been thinking about something like this. Do you/anybody with knowledge on the topic think that it would be a sustainable design

>>10409
which, the first or second idea? The first would definitely be useful, the second... I dunno.

>>10413
The first i think. I guess it would be similar to how google uses java for android if you were to use the linux kernel.

>>10441
The idea of writing a custom kernel for it does however sound quite interesting.

>>6462
How good is "Programming from the ground up"? I've started reading it and it seems quite nice but i want to know if I'm wasting my time.

>>10446
Do you already know a fair amount about assembler language?
If you do you may be wasting your time, but it's still a good read.
It's not a long book anyway. You should just finish it. It can't hurt you.

>>10442
A custom kernel in lisp, no less.

>>10457
I would say a custom kernel in lisp would make it less accessible than one in c for example. I think having a kernel built in something usually used for low level development would make more sense. C allows for more easy cross-architecture compilation and has high performance compilers compared with essentially anything

>>10457
>>10464
This has already been done:
https://common-lisp.net/project/movitz/
https://github.com/froggey/Mezzano

It doesn't feel right to talk about Lisp so much in the low level programming thread, mostly because Lisp already has a thread.

What assembler do you all use? What architectures do you know? I'm getting better with MIPS and GAS, mostly because there's an apparent lack of advanced MIPS assemblers like you would see for other architectures, like FASM. I'm also looking into Gforth's MIPS assembler.

It's interesting to see how a postfix assembler works. It only further helps solidify the difference between the assembler language, the syntax, and the instruction set itself, the semantics.

I'll repost this because it's appropriate for the thread:

 Bitfield:|12345678|12345678|12345678|12345678|
 Register:|opcodeRR|RRRrrrrr|RRRRRsha|mtfuncti|
Immediate:|opcodeRR|RRRrrrrr|xxxxxxxx|xxxxxxxx|
     Jump:|opcodeXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|

      opcode: Denotes the type of instruction.
RRRRR, rrrrr: Denotes the registers used by the instruction for sources and the destination.
       shamt: The shift amount, used for some instructions.
      functi: Denotes the function being used for register instructions, such as addition or a right-shift.
           x: Denotes a 16-bit immediate value.
           X: Denotes a 26-bit address.

Isn't it beautiful? The regularity both makes it easier to learn and also makes developing MIPS tools much simpler than for a complex architecture such as x86. I suppose that makes it ironic that MIPS tools are so easily outnumbered by x86.

>>10374
>>10381
>>10387
The adjective 'mock' was meant to describe the OS, not the Lisp. My OS is just a REPL that works like a shell. Different users have access to different namespaces and different file permissions. Initial namespace is the 'login' namespace which only exposes #'login and a few other things. That's the plan anyway.

>>6264
Not fiz-bin?

>>10465
I usually use whatever comes with my compiler for an assembler. I use Keil's assemblers for 8051 and ARM. They have pretty nice macro support. I use fasm for x86 but I don't write much x86 asm.

I can certainly appreciate the regularity of MIPS but I actually find more complicated ISAs that pack more instructions into less bytes more asthetically pleasing. Given the importance of instruction cache on the high end and code size on the low end I see a dense and more complicated ISA as one more way to eke every last bit of performance out of a chip.

Does anyone else try to find information on how old assemblers operated?

It seems valuable to know what assemblers were like when a great many programmers actually used them and it seems like good inspiration if you ever want to design your own, which I do.

Modern assemblers feel strange when you try to do much work with them directly.

>>11869
assemblers are *very* simple. check out some of the assemblers for the DCPU-16, that's probably close to how they used to be.