News for hackers. Stuff that matters.
Re:Mal – Make a Lisp, in 68 languages by spc476 on Tuesday September 12, 2017 @05:21PM (#15232891)
You climed in the wrong direction. What you want is assembly. That's where software ends up.

Also, it's interpreters all the way down. Even assembly is interpreted.

Re:Mal – Make a Lisp, in 68 languages by nickpsecurity on Tuesday September 12, 2017 @11:25PM (#15235273)
Which might be a Scheme CPU formally derived and verified via LISP-based tech:

https://www.cs.indiana.edu/pub/techreports/TR413.pdf

Or recently this way:

http://scheme2006.cs.uchicago.edu/05-saint-mleux.pdf

Interesting enough, the primitive versions of LISP that aren't high-performance (i.e. advanced compilers) could probably be done by hand in hardware where the whole thing was bootstrapped up with LISP-only tech. The LISP would start/stop at the abstract, state machines or RTL of the bootstrapped version.

EDIT: Good luck on making it through the hurricane. Feel for yall out there.

Re:Mal – Make a Lisp, in 68 languages by prophesi on Tuesday September 12, 2017 @06:36PM (#15233604)
Not the wrong direction, just not far enough.

Learning assembly is great, and every programmer should dive into at least a simpler version of it, but it's not exactly the best way to learn how your high-level language is implementing tail-call optimization.

Re:Mal – Make a Lisp, in 68 languages by flavio81 on Tuesday September 12, 2017 @07:05PM (#15233836)
>What you want is assembly.

Which you can code in a convenient way by using Lisp and Lisp macros to generate the <insert target CPU> machine language output using <insert target CPU> opcodes.

Re:Mal – Make a Lisp, in 68 languages by cabaalis on Tuesday September 12, 2017 @05:51PM (#15233188)
>Also, it's interpreters all the way down. Even assembly is interpreted.

Speak truth to power. Every time someone says this there seem to be nothing but haters.

Re:Mal – Make a Lisp, in 68 languages by dreamcompiler on Tuesday September 12, 2017 @10:33PM (#15235063)
> Every time someone says this there seem to be nothing but haters.

Because it's not completely true. If a CPU is microcoded, then it's accurate to say "assembly is interpreted" because every instruction is effectively an address into a lookup table of microinstructions. But in a non-microcoded (e.g. purely RISC) CPU, the bits of the instruction word are effectively enable and data lines to a bunch of hardware logic gates and flip-flops, which cause register transfers and arithmetic operations to happen. In this case, the ones and zeros in the instruction word are voltage levels on logic gates. Calling the latter "interpretation" is a stretch.

To be fair, there aren't many pure RISC implementations around these days. Most everything has some degree of microcode involved, so to that extent you're right.

Re:Mal – Make a Lisp, in 68 languages by kazinator on Wednesday September 13, 2017 @01:39AM (#15235835)
It's interpreted because the instructions are fetched one by one. A piano roll is intepreted, even though its holes just activate keys with a "horizontal encoding". It is interpreted because it moves through the piano, and a little piece of it activates a behavior any one time, without leaving a permanent record.
Re:Mal – Make a Lisp, in 68 languages by kazinator on Wednesday September 13, 2017 @01:38AM (#15235828)
Not only is machine code interpreted, the so-called "asynchronous interrupts" are just periodically polled for in between the fetching, decoding and executing.
Re:Mal – Make a Lisp, in 68 languages by omginternets on Tuesday September 12, 2017 @06:26PM (#15233510)
>Even assembly is interpreted.

Could you please elaborate on this point? I'm still very much in the cave.

Re:Mal – Make a Lisp, in 68 languages by spc476 on Tuesday September 12, 2017 @06:32PM (#15233557)
I'll use x86-32 for elaboration [1]. When the CPU sees the byte sequence 0xB8 0x90 0x41 0x5A 0x7B, it has to interpet what those bytes mean. It sees the 0xB8, so then it knows that you are loading the EAX register with an immedate value. The next four bytes (0x90, 0x41, 0x5A, 0x7B) are read and stored into EAX (as 0x7B5A4190, because Intel is little endian).

That is the case for all instructions. Each one is interpreted by the CPU. And for modern CPUs, even translated into an internal format that is futher interpreted.

[1] Sans power right now. Using my cellphone as a hot-spot and my iPad as a laptop. The aftermath of hurricanes is brutal in Florida.

Re:Mal – Make a Lisp, in 68 languages by omginternets on Wednesday September 13, 2017 @04:31AM (#15236496)
Gotcha, but then (unless I'm misunderstanding) one of these interpreters is not like the other. Namely, assembly 'interpretation' happens on bare metal. Were you previously suggesting that understanding a lisp interpreter will help in understanding CPU architecture?

(Good luck recovering from the hurricane! Keep your head down!)

Re:Mal – Make a Lisp, in 68 languages by spc476 on Wednesday September 13, 2017 @05:56PM (#15243097)
I was replying more to jospar's post about learning what an 'if' was, what a 'boolean' was, etc. What's an 'if'? Ultimately it's a comparison of two numbers and a transfer of control based upon said comparison. Some architectures that's one instruction, some two.