There's been an update posted a few days ago. Unfortunately, I think he's missing the point.



Every technical feature that he's discussed adding is possible to implement to some degree, but doesn't help with the real problems.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Hi White Flame (and welcome!)
I saw a rather unseemly mob, but I'm not sure I saw 'real problems' with the project.

The negative posts seem to be attacking a straw man: take a difficult example, suppose it to be necessary, and pronounce the project as hopeless.

In fact, I think the project has a loose goal, of producing C which is accurate and to some degree more useful for study than the machine code. (One might argue that C could never be useful, but again I don't see that as helpful - a decompilation will always have more potential readers than a disassembly.) Six months of full time effort by someone who knows what they are doing has every chance of producing something impressive. Much less time went into any of these forum posts than into that prototype, and yet the prototype actually does something interesting.

(As for my mob comment: I'd much rather see comments pitched as "I don't see how..." instead of "You can't possibly...", and "I wouldn't support this" instead of "This is hopeless and wrong-headed". If a friend comes up to a bunch of friends with a wild idea for building something, is rubbishing the idea the best response? Even if you know them well and have good reason to judge it over-ambitious, that seems unnecessarily hostile to me. In this case, we don't know well.)

Cheers
Ed

Those are the ones that will hold the unexpected secrets we want. Can we get them? I'm not sure. You can't make a program look for something that's entirely different from what you think it is. I'm not very optimistic, but I will say that I was all the more motivated to develop my method of servicing interrupts in high-level Forth with zero overhead on 65C02 when people said it couldn't be done but I already knew what I was going to do. It did not discourage me, but instead fired me up. I won't attack him, but I will say he has set the bar awfully high for himself, as I have done sometimes, and recognized that I had bit off a big chuck and I was going to have to come through for my employer. I had to perform. There was no choice.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I will simply say that his list of "Use $TECHNOLOGY to reveal $INFO" features that he plans to include do not close the gap between hand-written assembly and his goal of "Derive readable C that can be ported", even if he implements them completely.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

No need to wonder! He said:
"I do like how it can already detect do/while loops. That's really cool. "

(This was actually my internal prompt for the claim that the prototype can already do interesting things.)

(I'm not suggesting that gplus has become the place for 6502 discussions, but it's where he and I interact most these days)

Cheers
Ed

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Indeed - I was being helpful, for you and anyone else who might be interested.
Cheers
Ed

Well, the fundraiser is over and didn't draw much money. I feel kind of bad for the guy; if he just focused on the technical features he wanted to put in, but didn't frame it with generating "high-level, readable" handwaviness, he might have successfully raised funds.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I see Ulrich has released his state-of-play code as open source:
https://github.com/uli/decomp#readme

There are pointers there to a few articles he's written about the techniques he used.

(As the crowdfunding didn't get any significant money, I would suppose future progress, if any, will be at a slow pace.)

Cheers
Ed

I gave it a try with some of my own code. It's pretty impressive what it can do, but on the other hand there's still a lot that it can't. One particularly amusing bit:

This is part of my code that keeps track of the time. Apparently, the decompiler doesn't understand that the code after the 'bcc' always has the carry flag set, leading to:

I edited the code to fix the numbered variable names back into the original names.

Yes, he mentions the detection of branch-always idioms in his pieces. Doubtless you could never get 100% correct, so the question would be how often you get it wrong, and how your progress is in improving that. Also, what interactive tools you might have to assist.

Cheers
Ed