6502.org
http://forum.6502.org/

32 is the new 8-bit
http://forum.6502.org/viewtopic.php?f=10&t=2524		 Page 5 of 12
Author:  enso [ Thu Jun 06, 2013 6:04 am ]
Post subject:  Re: 32 is the new 8-bit
Arlet, looking at my notes I see that I was using the 'self-refresh' mode, which consumed a ridiculous amount of cycles. It would've made more sense to do a regular refresh during vertical blank, losing a few cycles here and there.

Thanks for the core! I wish I had it back then. The XESS vhdl core was a pain.

You have more patience here then I... I don't think this guy gets it (or wants to understand) about registers eating cycles and critical path delays slowing down the clock. Or using memory output without registers. Or instruction decoding, for that matter.

I've implemented a similar system to decode 6-bit instructions from 18-bit words years ago. Like I said before, if you happen to be using wider memory and have no choice, you have to do something like this. Knowing what I know today, if I had a meg of 32-bit ram, I'd sooner use the low 8 bits then mess around with this foolishness.

Thanks again.
Author:  Windfall [ Thu Jun 06, 2013 8:42 am ]
Post subject:  Re: 32 is the new 8-bit
Arlet wrote:
Windfall wrote:
Okay, I see. You've shifted the paths a little by preprocessing the opcode while it's not even registered yet. :shock: :D

In my core, the opcode is never registered. None of the incoming data bus is registered before processing.

Well, you do register it. Just in processed form. Which requires faster memory. But I suppose there are always tradeoffs to consider.
Arlet wrote:
Quote:
See what happened here ? The critical path may have become shorter here, since this replaces the memory access path with a combinatorial path involving only PW and the two least significant bits of the PC.

It only becomes shorter if PW/PWA are registers. But then you'll have to add the cycles to load those registers. In addition, you'll need muxes to grab the operand values.

I already said they were registers. And they're loaded at the same time as IR (their values are not needed until the next instruction), so there's no penalty.
Arlet wrote:
And what are you going to do when you load data ? If you use the same method, every LDA will require an extra cycle.

And did you consider STA ?

I explained all that before. Data could go via 'NOT request_instruction' and could arrive at the core as anything it chooses to be. Including directly.

Please do me and others the courtesy of reading what has been said and letting it sink in for a while before you react. I have to repeat myself endlessly, and I'm sure I'm not the only one annoyed by it.
Author:  Arlet [ Thu Jun 06, 2013 8:54 am ]
Post subject:  Re: 32 is the new 8-bit
I give up. Go ahead and show the code when you've implemented it.
Author:  GARTHWILSON [ Thu Jun 06, 2013 9:05 am ]
Post subject:  Re: 32 is the new 8-bit
Windfall, if I understand you correctly (albeit only partially understanding), I can imagine a valid way for your idea to become what amounts to an external pipeline that stays far enough ahead to avoid delays under certain conditions, although I'd be interested to see how various details are handled if/when you actually do it. I see problems with it, but that's not to say there aren't solutions to them. I've had the experience before however when I had ideas and everyone said it couldn't be done, and part of that may have been because I didn't explain myself well enough. More later.
Author:  Dr Jefyll [ Thu Jun 06, 2013 10:22 am ]
Post subject:  Re: 32 is the new 8-bit
Quote:
I've had the experience before however when I had ideas and everyone said it couldn't be done, and part of that may have been because I didn't explain myself well enough.
It's a good point, Garth. But, honestly, for this thread I kind of dread the idea of any more explaining! I've gotten a little bit burned out. Maybe that's partly due to reliance on English, which isn't especially well suited to the topic. Short of actual HDL, what's the alternative? If there's to be any further explanation, maybe it'd be worth considering a graphical presentation of the pipeline -- something in the form of the (nonsense) diagram below :?:

-- Jeff

Attachments:
pipeline_illustration.gif
pipeline_illustration.gif [ 6.28 KiB | Viewed 1410 times ]
Author:  Windfall [ Thu Jun 06, 2013 10:45 am ]
Post subject:  Re: 32 is the new 8-bit
Arlet wrote:
I give up. Go ahead and show the code when you've implemented it.

Again. I won't do that until some core author, who actually gets it (and clearly my expectations were too high here), is cooperating. Since this 8-to-32-bit trick, if it works properly, benefits the 'community' (for lack of a better word) a.k.a. all existing cores, I refuse to do all the work.
Author:  Windfall [ Thu Jun 06, 2013 10:51 am ]
Post subject:  Re: 32 is the new 8-bit
Dr Jefyll wrote:
If there's to be any further explanation, maybe it'd be worth considering a graphical presentation of the pipeline -- something in the form of the (nonsense) diagram below :?:

How about this. The registers are : PWA, PW, IR. Rest self explanatory. 'Whatever' is whatever Arlet decodes and stores based on the opcode.

Oh, and PW and PWA are sometimes not updated, depending on what part of the 64 incoming bits is copied to IR. I.e. that is not shown here.

Attachments:
File comment: Old situation.
Old.png
Old.png [ 1.93 KiB | Viewed 1394 times ]
File comment: New situation.
New.png
New.png [ 5.81 KiB | Viewed 1394 times ]
Author:  Tor [ Thu Jun 06, 2013 11:38 am ]
Post subject:  Re: 32 is the new 8-bit
Windfall wrote:
Arlet wrote:
I give up. Go ahead and show the code when you've implemented it.

Again. I won't do that until some core author, who actually gets it (and clearly my expectations were too high here), is cooperating. Since this 8-to-32-bit trick, if it works properly, benefits the 'community' (for lack of a better word) a.k.a. all existing cores, I refuse to do all the work.

As a neutral observer: The issue is that you are the one who came up with an idea for improving things, thus if others don't see it that way it's you who will have to prove that it is so.
This is the standard approach for all kinds of science and research.

-Tor
Author:  Windfall [ Thu Jun 06, 2013 12:01 pm ]
Post subject:  Re: 32 is the new 8-bit
Tor wrote:
Windfall wrote:
Arlet wrote:
I give up. Go ahead and show the code when you've implemented it.

Again. I won't do that until some core author, who actually gets it (and clearly my expectations were too high here), is cooperating. Since this 8-to-32-bit trick, if it works properly, benefits the 'community' (for lack of a better word) a.k.a. all existing cores, I refuse to do all the work.

As a neutral observer: The issue is that you are the one who came up with an idea for improving things, thus if others don't see it that way it's you who will have to prove that it is so.

I don't have to do anything, Tor. Let's start with that. I think this is an exciting idea, because it could speed up 6502 cores considerably, without much cost. But this is just hobby to me, so I could take or leave 'proving' it.
Tor wrote:
This is the standard approach for all kinds of science and research.

I didn't know we did science and research here. But, continuing with that rather lofty viewpoint, it is also standard approach to obtain cooperation from those more knowledgeable about some parts of the problem. The core needs to be changed. Since I'm not the one who knows it in detail, the author is, I am not the one to do core changes.
Author:  Tor [ Thu Jun 06, 2013 12:23 pm ]
Post subject:  Re: 32 is the new 8-bit
The burden of proof is always on the one who came up with the new idea. Particularly when others took a look at the idea and said it won't work. This is standard practice in every area of life.

-Tor
Author:  Windfall [ Thu Jun 06, 2013 12:30 pm ]
Post subject:  Re: 32 is the new 8-bit
Tor wrote:
The burden of proof is always on the one who came up with the new idea. Particularly when others took a look at the idea and said it won't work. This is standard practice in every area of life.

-Tor

There's no need to repeat your viewpoint. I've read it. And you have my response.
Author:  enso [ Thu Jun 06, 2013 4:00 pm ]
Post subject:  Re: 32 is the new 8-bit
HA! I can't believe the hubris. Let me paraphrase:

"Here is my great idea. I am smart. You are all too stupid to understand it. If one of you jerks agrees that they will use it sight unseen, 'all or nothing', I may actually create a demonstration. But don't get me wrong, I don't have to do anything here."

Amazingly, this genius has insulted everyone here, even those trying to defend him.
Author:  enso [ Thu Jun 06, 2013 8:59 pm ]
Post subject:  Re: 32 is the new 8-bit
Proposal to end this thread.

Friends, this thread has become more then unproductive. Let's take the high road. It is obvious that even asking for clarification will evoke a string of insults; any criticism will be met with outright abuse; and anything short of bowing to the greatness of this idea and the genius of the creator, will not suffice.

Should we, the 'community', ever be in a situation requiring 8-bit fetches from 32-bit memory, I think it's pretty clear that a muxing approach, with registers for the remaining bytes, is simply the only way to do this. And if someone decides to build a prefetch circuit to accelerate a 6502 core, they will make one. We will come up with something that works without this kind of discourse. Arguing over a non-problem with a 'solution' described in terminology no one can possibly understand is just a waste of time.

32 bit is still 32 bit, 8 bit is 8 bit, and 32 is hardly the new 8.
Author:  BigEd [ Thu Jun 06, 2013 9:09 pm ]
Post subject:  Re: 32 is the new 8-bit
Enso: better to leave a thread alone if you don't like it. Just stop responding and disable notifications.
Author:  BigDumbDinosaur [ Thu Jun 06, 2013 9:54 pm ]
Post subject:  Re: 32 is the new 8-bit
I can't recall how many times in the past I've run across individuals with "great ideas" who were not able or willing to make something concrete of them.

While Windfall's great idea might result in a 65xx core that actually will run faster with wide memory, all we have seen to date is (largely unsupported) theory—along with a palpable level of hubris. Why should others do the work of translating this theory into working hardware—something that will not be a trivial engineering exercise, and might not produce results of value? None of us has infinite time to invest in something that has been, in my opinion, poorly explained. Unless Windfall commits to creating a working core, I suspect his theory will remain just that. In other words, show us a proof of concept and then we'll talk.

I agree with Enso that we should abandon this thread.
Page 5 of 12 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/