It is currently Wed Nov 21, 2018 6:36 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Feb 07, 2014 12:16 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I took a while to survey the topic. To avoid sunk-cost bias from wrecking things, I'm going to ignore my ca65 macro packs and byuu's bass.

We start with the 65xx and SPC-700 architectures. Those have official assembly syntaxes and are supported by multiple assemblers. All good. But there are improvements to the tools that would suit some users better:

Familiar syntax

65xx has syntax that is pleasing to many programmers, and is the main one for programming the SNES. The SPC-700's syntax is of a different style that is unpleasant to some programmers, at the very least different which is added mental load. Since the SPC-700 has the same core architecture as the SNES's 65816 processor, it can be given a new assembly syntax in 65xx style that is easier for 65xx programmers to learn and switch to and from while programming on the SNES's 65816.

The familar syntax approach is a new instruction set architecture (ISA), only similar to 65xx and SPC-700. In general code in the new ISA can't be assembled as 65xx code (more instructions, differing semantics for some common mnemonics), and can't be assembled as standard SPC-700 code (same instructions, but different mnemonics/syntax). One either writes new code for this ISA, or does a one-time port of 65xx/SPC-700 code to it. Regardless, there's no need for syntax/semantic compatibility since it's a new ISA meant to be directly coded for.

The question of syntax and semantics is entirely a style issue, so there is complete flexibility for the new ISA to be whatever is most pleasant to program with.

One possible additional constraint mentioned was having a 1:1 correspondence between the new ISA's mnemonics and SPC-700 instructions. That is, each instruction in the new ISA generates exactly one SPC-700 opcode. This allows a disassembler's output to match the assembler input.

Code sharing

SPC-700 is very similar to the 65xx and the core 65xx instructions are supported virtually identically. This means that there is a direct/nearly-direct correspondence between these instructions, and conversion can be done automatically. It could be a script that converts source code between formats, or macros that do it during assembly.

Naturally the code sharing approach doesn't introduce any new assembly language or syntax, since its purpose it merely to allow code in (a subset of) standard 65xx and SPC-700 syntax to coexist in an SPC-700 project. It should allow both to be used in the same source file, with as few restrictions on the 65xx code as possible, and for code that is allowed, as few differences in semantics as reasonably possible.

To avoid silent bugs when moving working 65xx code over, the supported 65xx mnemonics should have semantics as close to nearly identical as practically possible, and list instructions/cases for which it's not so the user can scan the code for them and be mindful when changing it. For example, the 65xx PLA sets flags based on A, while the near-equivalent POP A on SPC-700 doesn't set flags. Translating PLA into POP A; AND A,#$FF; results in the same flag behavior at minor cost. At the impractical end is the 65xx RTS which pops the 16-bit return address off the stack, increments it by one, then jumps to it. The SPC-700 has RET, which does the same except it doesn't increment it. Translating between the two would be prohibitively expensive and unnecessary in most cases as 65xx code normally uses RTS as a complement to JSR, which behave the same on SPC-700 as an RET after a CALL.

Preferably when sharing SPC-700 code, it should be written in SPC-700 assembly language. This ensures that people using one of the multiple SPC-700 assemblers can use it with minimal change. The code sharing should preferably only be used inside a project, to faciliate sharing.

Merging the two

It may be possible to merge the two improvements, if one designed the new ISA so that it had the same syntax and semantics (where reasonably possible) as the common 65xx instructions, and didn't conflict with standard SPC-700 instructions and addressing modes. This runs the risk of trying to meet too many constraints without compensating benefit, and resulting in a less-useful design.

As far as constraints go, there's not much to relax of the constraints on the code-sharing improvement. Its purpose is to allow coexistence of standard 65xx and SPC-700 code in a project, thus it needs to accept the syntaxes of both, and provide 65xx semantics where reasonably possible. If these were to be violated merely to allow a preferred syntax in the new ISA, then the new ISA might as well not hamper itself with remaining compatible with 65xx/SPC-700 code and get the maximum benefit of being able to use whatever syntax is most pleasant for its users. Put another way, if the new ISA were incompatible with standard 65xx and/or SPC-700 code, such code would have to be ported to work with the new ISA, thus there'd be no point in trying to support 65xx or SPC-700 code and limiting the ISA's design choices.

If one didn't care for standard SPC-700 compatibility, one might be able to make the new ISA allow 65xx code sharing with less effort. The same steps would need to be taken as above for avoid silent bugs. Any new mnemonics should not match any 65xx ones, and any common mnemonics should have semantics as close as practically possible. The 1:1 mnemonic-opcode constraint might conflict with avoiding silent bugs, or require changing an almost-same behaving instruction to have a different mnemonic than the 65xx near-equivalent.


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 2:06 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1390
Quote:
byuu, your messages to me here and in the other thread have been hurtful and I dread them. I'd really appreciate if you could stick to the technical arguments. You keep lamenting about how things can't happen, and these negative predictions are detrimental to me even participating at this point. I'm trying to understand the situation and offer my ideas, but I don't want to get attacked for misunderstanding or asking for clarification.


You're one of maybe ten people I truly have very deep respect for on the internet. I absolutely meant no disrespect or rudeness at all, so I apologize if you took it that way.

This is really why I hate the internet, you really can't convey emotion or intent behind words. Personally, I'm participating in this thread with no emotions whatsoever. I'm not angry, upset, or anything of the sort. I'm honestly not even that concerned about this. I've had my SPC700 syntax in for around two years now, I just do my own thing.

I have always been a very direct person. If you were to cook something and asked me what I thought, and I didn't like it, I'd tell you it sucked. Some would see that as rude, I would see it as honest feedback. I certainly could be an encouragement echo chamber to say your food was great, but why even ask me what I thought if you already knew the answer would be positive no matter what?

But like I said, I've always greatly appreciated your insights and help, so if you aren't able to look through my words and see there's no ill intent, I would be willing to filter what I say. The last thing I'd want is to upset you. (Again, there's no sarcasm or hidden meanings or belittling implied there. That's an honest statement.) I'd be open to your advice on how to do that, tact really has never been my strong suit.

Back onto the thread ... yes, I am a very negative/pessimistic person. It stems from 15 years of experience. Most people don't like to collaborate on improvements: they either like to stick with the norm, or innovate on their own. Myself, if I think I can do something better, I'll throw out backward-compatibility and do it the way I think is best. I'm frequently ripped apart all over the internet any time I dare deviate one iota from the established expectations. Far worse than anything in this thread (I've been called insane for sorting by game instead of by filetype, autistic for writing a high-requirement emulator, a Nazi for wanting to rename SMC files to SFC files, etc.) So I have a very thick skin.

I spent two years eliciting feedback for an IPS successor. Eventually I finally release it, and immediately everyone hates it. I tried for months to get other SNES emulators and set maintainers interested in board markups. I eventually just gave up and did it myself, and even went and bought 2000+ games to get the markups myself. I spent a good week or two arguing here about iNES and that went absolutely nowhere. Received zero interest in my idea to make a truly portable micro-language to externally emulate NES mappers. When I try and think of successful format collaborations with others, nothing comes to mind at all. (When we avoid formats/specifications, things go great, eg coprocessor research.) I love it when people work with me, but I'm perfectly fine being entirely self-sufficient, too.

When I look at this thread, my honest impression is that we both had different goals. I don't see a strong reason why we both have to compromise. So if you don't want to, it's not like it's a bad thing, it's just what it is. From your own words:

"I have little interest in trying to make custom 6502-like mnemonics for SPC-700 instructions"
"I just looked at some of your SPC-700 instructions in 6502 clothing and I'm wondering what the benefit is"

If you like the idea, I'd love your participation. If you don't, then I wouldn't want you to dredge through it just for my sake.
But it sure sounds like the latter, and that's why I said that we weren't likely to reach a unified syntax.

Again, I don't even think we necessarily need to. Your idea has a specific utility, as does mine. When I made BML, I could have done the same with XML for the sake of uniformity. But instead I specialized to get a more optimal solution to what I wanted. I had no use for entities, document validation, tags within text, etc. Instead I made something far easier to edit by hand. That mattered a lot when I hand-created 750 game definitions in a row. I see your ca65 macro pack as an optimal solution to ca65 users wanting identical code to run on both the 6502 and SPC700. I see my syntax as an optimal solution for not having to learn two wholly different mnemonics to work on the core SNES system. If we attempt to make a unified syntax, which I am willing to try, we will end up both succeeding less in our original goals.

So again, tepples' goal was one syntax to rule them all. I say it's not doable, and I'm deeply sorry that upsets you, but it's my honest opinion, and I don't know what to do other than lie about it. My goal, though, is to recognize that both of us have amazing ideas and great insights, and that these insights might help me improve your ca65 pack, and yours might help me improve my bass table. So what if we don't reach 1:1 parity? Let's see how close we can get anyway.

I've gotten the impression lately that you weren't all that interested in my input. When I suggested different ideas for your ca65 pack and for the SPC700 test ROMs, you seemed to dismiss them entirely, as you already made what you wanted. So what I took away was that you weren't too interested in listening to feedback and making changes. You had your way of doing things, and that's perfectly okay, nothing wrong with that. I certainly have my own projects where I won't consider any changes. Sometimes what a project needs to be successful is a strong leader / decision-maker, to prevent infinite bikeshedding and get a unified vision out there that isn't a clusterfuck of 80-ways-to-do-the-same-thing like most ISO/ANSI/IEEE specifications.

If you do want to participate ... my most pressing issue that I've love advice on, is how to handle the opcodes that only exist in SPC700.

dbnz, cbne, bbc/bbs[0-7], ora that doesn't apply to the accumulator, and multi-operand opcodes since the 65xx already uses , in addressing. My ideas are in the bass table and in my SNES debugger loki, but I'm absolutely willing to change any of it.

I think the 1:1 parallels eg "mov a,#$00 -> lda #$00" is very easy for us all to agree on, and need not be discussed much.


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 4:57 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1390
Thinking more about blargg's version. I think I see the source of confusion.

So, blargg has not in any way created a 6502 syntax for the SPC700. Instead, he's written two programs in one: the first, is a 6502 -> SPC700 opcode translator; the second, is an SPC700 assembler. They are combined into one program, ca65. And as such, we are addressing it like an SPC700 alternate instruction set, because that is what it appears to be. But that's not it at all. It would be fairer to say that it's a source code translator, along the lines of Java -> C translators.

In this context, it doesn't make sense for it to support SPC700-specific opcode mnemonics. Or even SPC700-specific instructions at all, except in the event that using one would better simulate 6502 behavior, if that occurs at all.


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 8:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20792
Location: NE Indiana, USA (NTSC)
Thank you blargg for the comprehensive write-up.

blargg wrote:
Translating between the two would be prohibitively expensive and unnecessary in most cases as 65xx code normally uses RTS as a complement to JSR, which behave the same on SPC-700 as an RET after a CALL.

The one big change in this case would be to tables used by dispatchers using the RTS trick. This leaves PLA/PLX/PLY as the significant difference.

byuu wrote:
If you were to cook something and asked me what I thought, and I didn't like it, I'd tell you it sucked. Some would see that as rude, I would see it as honest feedback.

Most of the time,* culture leaves open a way to give honest feedback without rudeness. "I see a lot of room for improvement."

byuu wrote:
Myself, if I think I can do something better, I'll throw out backward-compatibility and do it the way I think is best. I'm frequently ripped apart all over the internet any time I dare deviate one iota from the established expectations.

Sometimes the answer has to be "the cheese is moving, so move with it."

byuu wrote:
Received zero interest in my idea to make a truly portable micro-language to externally emulate NES mappers.

If only you'd told zzo38, who had been working on a similar idea.

byuu wrote:
So again, tepples' goal was one syntax to rule them all. I say it's not doable, and I'm deeply sorry that upsets you

I'm not upset. At least I learned that handling of PLA is the big sticking point.


* Feel free to point out exceptions.


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 12:51 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 770
tepples wrote:
byuu wrote:
If you were to cook something and asked me what I thought, and I didn't like it, I'd tell you it sucked. Some would see that as rude, I would see it as honest feedback.

Most of the time,* culture leaves open a way to give honest feedback without rudeness. "I see a lot of room for improvement."
* Feel free to point out exceptions.

"Does this dress make me look fat?"

...shit...


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 1:12 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1390
Hmm, let me try ...

> "Does this dress make me look fat?"

a) You have filled in the dress well.
b) You have expertly taken advantage of the space available in the dress.
c) Good news, you won't need to exchange your dress for a smaller size.
d) The dress does not make you look fat. The fat makes you look fat.


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 5:32 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
"I have little interest in trying to make custom 6502-like mnemonics for SPC-700 instructions"
"I just looked at some of your SPC-700 instructions in 6502 clothing and I'm wondering what the benefit is"

If you like the idea, I'd love your participation. If you don't, then I wouldn't want you to dredge through it just for my sake.
But it sure sounds like the latter, and that's why I said that we weren't likely to reach a unified syntax.


I'd like my macro pack to not unnecessarily be incompatible with something you and tepples (and hopefully others) are working on. I don't want needless technical problems that could be worked out. That's why I want to understand what you and him are planning. Then we can see what the technical landscape is and where each of our goals fall, and what sorts of solutions meet them all more smoothly than others.

Yes, I don't plan on working on a 65xx-style instruction set for the SPC-700. I'd share more of what seem practical problems with it but I don't get the sense that there's room for that, which is fine, because it doesn't really matter either way. I don't want anything I do to get in the way, which is why I'd like to understand at least the scope and goals, so I can see what is eliminatable and what is due to inherent incompatibility of the technical goals.

Quote:
If we attempt to make a unified syntax, which I am willing to try, we will end up both succeeding less in our original goals.

That may be the case, but I'm still interested in clarifying the goals, solutions, and seeing what actual conflicts they have.

Quote:
I say it's not doable, and I'm deeply sorry that upsets you, but it's my honest opinion, and I don't know what to do other than lie about it.

The frustrating thing was the implication that it was due to me being inflexible or some other non-technical point. The way I approach these is to push for clarity of everyone's ideas and goals, to explore them all relentlessly until they're fully understood. Then look at the various issues and costs, and finally come back to our individual goals and see how they arrange things, and use them to further calculate costs and benefits to make choices where there are tradeoffs. If there are problems that force taking a less-ambitious approach, I want to be able to explain them and have them clearly justify leaving them unsolved.

Quote:
[...] two programs in one: the first, is a 6502 -> SPC700 opcode translator; the second, is an SPC700 assembler. They are combined into one program, ca65. And as such, we are addressing it like an SPC700 alternate instruction set, because that is what it appears to be. But that's not it at all. It would be fairer to say that it's a source code translator, along the lines of Java -> C translators.

The SPC-700 part is actually separate. You can use just it, and use ca65 as a standard SPC-700 assembler; no 65xx instructions. You can use a second header in addition and get the core 65xx instructions *and* SPC-700 instructions.

I'm trying to find a response to the survey I posted. My main interest in the new ISA is that it not trade off interoperability with everything else for some minor stylistic freedom.

Will the new ISA allow coexistence with standadrd SPC-700 assembly? Disallowing that would be unfortunate because anyone using the new ISA wouldn't be able to use SPC-700 code without rewriting it. It would also tend to polarize demo code and routines into two incompatible groups (whereas keeping SPC-700 compatibility means it is the "portable" language), which seems the opposite effect you want on the community.

Will the new ISA attempt to make 65xx code using the common set of instructions assemble the same and work the same (other than POP and RET differing slightly)?


Top
 Profile  
 
PostPosted: Fri Feb 07, 2014 9:59 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1390
> Then we can see what the technical landscape is and where each of our goals fall, and what sorts of solutions meet them all more smoothly than others.

So far, one of the big ones is flags. Many platforms have "inc <reg>", yet their flags will act differently between 6502/x86/etc.

With your goal of having the code work on both areas, the and #$ff is a good response to PLA. With my goal of just having nicer mnemonics, I wouldn't be able to insert the additional instruction after it. Our shared understanding is to use PLA instead of some other term. We both like the aesthetic of 65xx here.

> The frustrating thing was the implication that it was due to me being inflexible or some other non-technical point.

That was not in any way what I was trying to imply. Apologies if I made it seem that way.

To me, I think you have your goal, and I have my goal, and they are not 100% compatible. As I said, I'd like to bounce ideas off each other to maybe improve each of our ideas, but I don't expect perfect compatibility between divergent goals.

Unfortunately it seems that instead of talking about the idea at hand, we're going to spend ten pages talking about what we feel the idea is about. We've yet to even begin to cover any of the interesting technical points and we're on post #22 :/

> My main interest in the new ISA is that it not trade off interoperability with everything else for some minor stylistic freedom.

That is exactly what it is. You downplay it a bit by saying minor, but I can see how if it's not an issue to you, you would feel that way.

The goal here is a 1:1 mapping of SPC700 official mnemonic <> 65xx-like mnemonic. If that goal doesn't interest you, or you don't like it, that's fine. I can continue developing it independently. If it does, then I'd like to hear your feedback on what to call the various SPC700-only instructions to fit the 65xx mold.

If you're worried it's going to split up existing code, well, you're right. If it catches on, it will do just that.

I think our styles and ideals just diverge here. You see no reason to modify existing standards for elegance alone, whereas I see no reason not to improve an existing standard where possible. Reasonable people can disagree on whether the changes are improvements. In this case, I think it's a worthwhile improvement.

> Will the new ISA allow coexistence with standadrd SPC-700 assembly?

It's a table-based assembler (and you can even modify the table dynamically), so yes that is entirely possible. I would hope someone wouldn't interleave the two formats in the same exact function, but they could have one function in traditional syntax one in another. That's still not ideal, I suppose.

One of the interesting points of this syntax though is that it's entirely amenable to direct machine-based translation, much like those fancy C code formatters.

If you don't like SPC700 syntax, there is a literal 1:1 transformation to the 65xx-syntax I am proposing. And vice versa. No instructions are added / removed / changed in any way. The resulting binary is identical in either format.

> Will the new ISA attempt to make 65xx code using the common set of instructions assemble the same and work the same (other than POP and RET differing slightly)?

Having trouble with this question. POP/RET are the known differences. If there are more differences like this, they will also remain different. All I am attempting to do is rename each mnemonic to a more 65xx-like name. It should mostly reflect what's going on to a 65xx programmer, but should not be reason to think it's literally a 65xx chip. You will still have to learn the differences between the chips.


Top
 Profile  
 
PostPosted: Sat Feb 08, 2014 9:32 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20792
Location: NE Indiana, USA (NTSC)
byuu wrote:
I would hope someone wouldn't interleave the two formats in the same exact function, but they could have one function in traditional syntax one in another. That's still not ideal, I suppose.

I can see someone getting in the habit of using MOS syntax for instructions present in the 6502 family and Sony syntax for other instructions, depending on what ends up happening with the syntax for the non-65C02 instructions.

So for the "code sharing" side of the equation, I'd recommend adding a few macros used by shared code.
  • The macro RTSADDR x, y, z, ... would emit .WORD x, y, z, ... in SPC700 mode or .WORD (x)-1, (y)-1, (z)-1, ... in 6502 mode.
  • The macro PLAS ("pull A and set flags") would emit PLA AND #$FF in SPC700 mode or PLA in 6502. The name is inspired by ARM's S suffix on ALU operations that affect the flags.

Code written for sharing would use RTSADDR and PLAS, allowing code sharing (blargg's goal) along with 1:1 correspondence of the actual mnemonics after macro expansion (byuu's goal). In the language of the C standard, PLA would mean "flags NZ are implementation-defined" and therefore nonportable, while PLAS would mean "flags NZ are set based on the value pulled from the stack."

Anyway, AND #$FF isn't the first instruction I would have guessed at first for "set NZ flags based on current value of A". Is there a reason why ORA #$00 or EOR #$00 wouldn't work?


Top
 Profile  
 
PostPosted: Sat Feb 08, 2014 11:28 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1390
That forces me back to four-letter opcodes.

But you know, that's honestly not a bad idea.

My disassembler / tracer would show: pla; and #$ff (zero interest in trying to 'roll-up' opcodes there)

But my assembler could easily take plas for that, and plas could exist in both 65816 and SPC700 mode. It'd just be an alias in the former.

And being forced back to four letters, I could handle cbne and dbnz so much more eloquently.


Top
 Profile  
 
PostPosted: Sat Feb 08, 2014 2:03 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
tepples wrote:
The macro RTSADDR x, y, z, ... would emit .WORD x, y, z, ... in SPC700 mode or .WORD (x)-1, (y)-1, (z)-1, ... in 6502 mode. [*]The macro PLAS ("pull A and set flags") would emit PLA AND #$FF in SPC700 mode or PLA in 6502. The name is inspired by ARM's S suffix on ALU operations that affect the flags.


How about an RTSADJ constant that's 1 on 65xx and 0 on SPC-700? Then the above macro can be built unconditionally by the user, along with any other handling (like manually pushing an address to later return to):
.WORD (x)-RTSADJ, (y)-RTSADJ, (z)-RTSADJ, ...

As for the pop instructions, maybe PFA could signal pull and set flags and stay a three-character mnemonic. You'd also have PFX and PFY of course. And yeah, AND, ORA, and EOR work just as well, and are probably clearer, as AND suggests masking something off (and OR/XOR with zero is a common NOP on RISC). For X and Y you can use an increment/decrement pair (two bytes like the A case).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group