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

41–50 of 59 posts

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

#41

Post by ddingus »

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.

Well, I have written a lot of code on 6502.

What you name is the value to be operated on, and that is indexed, zpage, immediate, etc... the accumulator is not named. There are two or three bytes, one instruction, one or two for value or address.

Same for things like ADC, the accumulator is where it will happen, the things you name are values and addresses.

LSL, LSR can just be stated, one byte instructions that operate on the accumulator, which does not need to be specified.

6502 is really basic. The accumulator is the working register for many things. The index registers are for indexing. One does not do LDX $c000, A for example.

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

#42

Post by EvenThisAcronym »

pcwalton wrote: post #24
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…

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'…

> That's why we get so many complaints from C++ and D developers that you can't do certain things. But Rust sticks with its strongly-typed generics, because Rust has always tried hard to strike a balance between code expressivity and maintainability.

In what sense are Rust macros "strongly-typed"? D and C++ templates are also strongly typed, just like the rest of the language.

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

#43

Post by pvg »

ddingus wrote: post #41
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.

Well, I have written a lot of code on 6502. What you name is the value to be operated on, and that is indexed, zpage, immediate, etc... the accumulator is not named. There are two or three bytes, one instruction, one or two for value or address. Same for things like ADC, the accumulator is where it will happen, the things you name are values and addresses. LSL, LSR can just be stated, one byte instructions that opera…

I believe you. But it was, quite typically, like you can see in the Woz code above. Or from '6502 Assembly Language Subroutines', 1982 vintage.

http://i.imgur.com/jreIWA5.png

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

#45

Post by ddingus »

pvg wrote: post #43
ddingus wrote: post #41

Earlier quoted context omitted.

Well, I have written a lot of code on 6502. What you name is the value to be operated on, and that is indexed, zpage, immediate, etc... the accumulator is not named. There are two or three bytes, one instruction, one or two for value or address. Same for things like ADC, the accumulator is where it will happen, the things you name are values and addresses. LSL, LSR can just be stated, one byte instructions that opera…

I believe you. But it was, quite typically, like you can see in the Woz code above. Or from '6502 Assembly Language Subroutines', 1982 vintage. http://i.imgur.com/jreIWA5.png

Yeah, it can be. No worries. Guess I never assembled on something that required it.

Fun old times in any case. That chip provided just enough, and no more.

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

#46

Post by pcwalton »

EvenThisAcronym wrote: post #42
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'…

> That's why we get so many complaints from C++ and D developers that you can't do certain things. But Rust sticks with its strongly-typed generics, because Rust has always tried hard to strike a balance between code expressivity and maintainability. In what sense are Rust macros "strongly-typed"? D and C++ templates are also strongly typed, just like the rest of the language.

Rust generics are strongly typed. C++ and D templates are, however, untyped. You can get errors at template instantiation time in C++ and D, because the compiler makes no attempt to ensure that the types your template operates on actually support the operations you're performing on them at the time you declare the template. In Rust (and basically every other language), though, the compiler typechecks your templates at the time you write them, so template instantiation can never result in errors inside the template.

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

#47

Post by evincarofautumn »

sklogic wrote: post #21
mcguire wrote: post #14

Earlier quoted context omitted.

If your macros aren't ugly, you're doing it wrong.

Macros should never be ugly. There are multiple ways of using compile-time metaprogramming in a nice and clean way. Maybe even in Rust, although I have not tried it yet.

If your macro is ugly, but it makes your code pretty, it might mean you’ve successfully sequestered some ugliness, which is probably a good thing.

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

#48

Post by pjmlp »

pcwalton wrote: post #39
Animats wrote: post #38

Earlier quoted context omitted.

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.

You are missing the point.

It is not the ORM library or the 6502 Assembler.

It is the library written by the clever guy on the third floor from blue team, for the new product being developed at Corpo X.

However I also have seen lots of convoluted code, exactly because such expressiveness is missing from the language.

For example, JVM bytecode manipulation or use of external code generators.

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

#49

Post by vardump »

to3m wrote: post #36
vardump wrote: post #32

Earlier quoted context omitted.

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!

Ok, 6510. Regardless I was talking about C64. You can't safely use addresses 0 or 1, because they're memory mapped I/O.

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

#50

Post by bsaul »

pcwalton wrote: post #24
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…

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'…

Maybe there still should be a compiler option to automatically evaluate the degree of abstraction complexity of a code, much like cyclomatic complexity, to prevent abuses ?
Post reply on HN