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

A MOS6502 assembler impleme​nted as a Rust macro

play.rust-lang.org

Post reply on HN
Print view View original

31–40 of 59 posts

Re: A MOS6502 assembler impleme​nted as a Rust macro

#31

Post by pcwalton »

vardump wrote: post #26
pcwalton wrote: post #24

Earlier quoted context omitted.

This is silly. Rust could not achieve its performance and safety goals without macros and generics. Generics may have been optional for Go (I don't agree, but let's go with it), but there is no way to achieve zero-cost memory safety without generics (while supporting first-class references and dynamic allocation). Rust generics are deliberately less expressive than C++ templates, in that they're strongly typed. That'…

Animats had a very important point. While magic is so attractive and perhaps even useful in moderation, it causes so much damage in a large code base. In C++, you get this damage from for example operator overload abuse (ok for math, not many other defensible uses), template abuse (ok in moderation), ninja exceptions and inheritance (especially multiple inheritance, ugh). Anyways, if Rust proves to be a feasible work…

And my point is that nobody would ever deploy this to production. Would you say you're worried about Go becoming C++ if someone posted a quine written in Go to HN?

By the way, Rust has no "template abuse", "ninja exceptions", or "inheritance".

Re: A MOS6502 assembler impleme​nted as a Rust macro

#32

Post by vardump »

pvg wrote: post #25
ddingus wrote: post #20

Earlier quoted context omitted.

The accumulator is the only register those work with. It was very common to not specify it.at all. I actually never have in all the 6502 assembly code I've ever written. Wasn't required.

I don't think that's true. http://www.downloads.reactivemicro.com/Public/Users/David_Cr... Code is straight from the Red Book listings. Search for ROR - accumulator (shown explicitly), indexed, you name it. 4 modes each.

Memory operand is not a register operand. Unless you're one of those who consider 6502 zero page as 254 registers (IIRC, you couldn't use addresses 0 and 1, at least on C64, because they were used for ROM visibility and I/O control).

Re: A MOS6502 assembler impleme​nted as a Rust macro

#33

Post by nickpsecurity »

sklogic wrote: post #29
Animats wrote: post #23

Earlier quoted context omitted.

When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…

> It's so easy to write useful but awful things with them, and they're really hard to fix and debug. And it is even easier to write useful, beautiful things with macros, which are really easy to fix and debug.

Back when I did a 4GL with them, my amateur trick was to write and test them like normal programs first. Then in the templated form as a normal program. Then do macros. On first two, I can use any technique known to benefit software quality. For programming in the large, interface checks that enforce correct usage are a straight-forward solution.

Curious, with your LISP and ML background, what method or methods do you use to ensure your macros are correct and easy to debug?

Re: A MOS6502 assembler impleme​nted as a Rust macro

#34

Post by vardump »

pcwalton wrote: post #31
vardump wrote: post #26

Earlier quoted context omitted.

Animats had a very important point. While magic is so attractive and perhaps even useful in moderation, it causes so much damage in a large code base. In C++, you get this damage from for example operator overload abuse (ok for math, not many other defensible uses), template abuse (ok in moderation), ninja exceptions and inheritance (especially multiple inheritance, ugh). Anyways, if Rust proves to be a feasible work…

And my point is that nobody would ever deploy this to production. Would you say you're worried about Go becoming C++ if someone posted a quine written in Go to HN? By the way, Rust has no "template abuse", "ninja exceptions", or "inheritance".

I do think Rust is currently the most likely language to become the C++ killer. And attract significant number of developers from other major commercial languages/platforms as well.

Rust might eventually become the new industry standard. That'd be a clear improvement for sure.

But we'll see what happens. Hopefully there'll be no Rust committees at least.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#35

Post by sklogic »

nickpsecurity wrote: post #33
sklogic wrote: post #29

Earlier quoted context omitted.

> It's so easy to write useful but awful things with them, and they're really hard to fix and debug. And it is even easier to write useful, beautiful things with macros, which are really easy to fix and debug.

Back when I did a 4GL with them, my amateur trick was to write and test them like normal programs first. Then in the templated form as a normal program. Then do macros. On first two, I can use any technique known to benefit software quality. For programming in the large, interface checks that enforce correct usage are a straight-forward solution. Curious, with your LISP and ML background, what method or methods do yo…

A couple of very simple tricks:

Macros must be staged - similarly to a good practice of not having too big functions, macros also must be small, and must transform code in small steps, with more macros further breaking the result down. Ideally, each macro must be a trivial rewrite doing only one small thing.

Another trick is to have a bunch of macros that would inject debugging output when enabled. Wrap every macro definition body in such a macro, and, with debugging turned on (can be selective), both source and output would be displayed. Another macro can be used to inject debugging info into a generated code.

I usually start writing macros the other way around - not from a code I'd like to see generated, but from a final form. Once I find the code with macros passable, I'll start implementing the macros, in small steps.

Same applies to a DSL design in general - first I write a code I want to see, and only then I fill in an implementation.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#36

Post by to3m »

vardump wrote: post #32
pvg wrote: post #25

Earlier quoted context omitted.

I don't think that's true. http://www.downloads.reactivemicro.com/Public/Users/David_Cr... Code is straight from the Red Book listings. Search for ROR - accumulator (shown explicitly), indexed, you name it. 4 modes each.

Memory operand is not a register operand. Unless you're one of those who consider 6502 zero page as 254 registers (IIRC, you couldn't use addresses 0 and 1, at least on C64, because they were used for ROM visibility and I/O control).

The C64 used the 6510, not the 6502. The zero page definitely has 256 bytes in it normally!

Re: A MOS6502 assembler impleme​nted as a Rust macro

#37

Post by jstimpfle »

Animats wrote: post #23
JustSomeNobody wrote: post #19

Earlier quoted context omitted.

Being a developer myself, I'm well aware of this. Still, it's ugly.

When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…

> This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this.

> C++ went down this road.

Also a big problem in the Haskell community. Trying to prove all sorts of complicated properties in a simple type system leads to overcomplicated design.

I don't think I'm against static code generation. But it incurs mental overhead. If you do it using a language which wasn't designed for that, much more so.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#38

Post by Animats »

pcwalton wrote: post #31
vardump wrote: post #26

Earlier quoted context omitted.

Animats had a very important point. While magic is so attractive and perhaps even useful in moderation, it causes so much damage in a large code base. In C++, you get this damage from for example operator overload abuse (ok for math, not many other defensible uses), template abuse (ok in moderation), ninja exceptions and inheritance (especially multiple inheritance, ugh). Anyways, if Rust proves to be a feasible work…

And my point is that nobody would ever deploy this to production. Would you say you're worried about Go becoming C++ if someone posted a quine written in Go to HN? By the way, Rust has no "template abuse", "ninja exceptions", or "inheritance".

You end up with it in production because some lower level library uses it.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#39

Post by pcwalton »

Animats wrote: post #38
pcwalton wrote: post #31

Earlier quoted context omitted.

And my point is that nobody would ever deploy this to production. Would you say you're worried about Go becoming C++ if someone posted a quine written in Go to HN? By the way, Rust has no "template abuse", "ninja exceptions", or "inheritance".

You end up with it in production because some lower level library uses it.

No Rust production program will ever transitively depend on a library with a 6502 assembler written in the macro language.

Re: A MOS6502 assembler impleme​nted as a Rust macro

#40

Post by lifthrasiir »

Animats wrote: post #23
JustSomeNobody wrote: post #19

Earlier quoted context omitted.

Being a developer myself, I'm well aware of this. Still, it's ugly.

When I see this, I understand why the Go crowd didn't put generics or macros in Go. It's so easy to write useful but awful things with them, and they're really hard to fix and debug. This is getting to be a big problem with Rust. The language, or maybe its community, encourages cutesy stuff like this. Remember "Diesel", the Rust compiler for SQL, from a few days ago? Just because you can doesn't mean you should. Too…

I can partly understand your points. I actually hated the "traditions" like Just Another Perl Hacker because it strongly gives an illusion of Perl as an obfuscated language.

My corresponding counterpoint is that you can write an obfuscated code in any language, no exception---probably a side-effect of Turing-completeness. If people has a general dislike towards too much magic and magic can be replaced with science^W saner alternatives there is no problem. The problem arises when you have to rely on magic for the certain class of tasks; it's no doubt that C++ (even the modern one) has this problem, but I think it is too early to claim that Rust has the same symptom.

Post reply on HN