New soft processor core paper publisher?

Err, what is this belief based on? I mean, you might be right, but I never heard that before.

Andrew.

Reply to
Andrew Haley
Loading thread data ...

You might want to fix your attribution line... What you replied to were not my words.

Rick

--

Rick
Reply to
rickman

post the verilog soon.

I'd be interested in reading the design document, but this is what I find at Opencores...

HIVE - a 32 bit, 8 thread, 4 register/stack hybrid, pipelined verilog soft processor core :: Overview Overview News Downloads Bugtracker

Project maintainers

Wallin, Eric Details

Name: hive Created: Jun 22, 2013 Updated: Jun 23, 2013 SVN: No files checked in

--

Rick
Reply to
rickman

What aspect of a processor can make implementation of semaphores impossible?

--

Rick
Reply to
rickman

Lack of atomic operations.

Rob.

Reply to
Rob Doyle

What you just said in response to my question about why you *can't* pick Forth is, "because it doesn't suit me". That's fair enough, but not as much about Forth as it is about your preferences and biases.

I think you will get some disagreement on that point.

I am no expert, so far be it from me to defend Forth in this regard, but my experience is that if you are having trouble writing code in Forth, you don't "get it".

I've mentioned many times I think the first time I can recall hearing "the word". I liked the idea of Forth, but was having trouble writing code in it for the various reasons that people give, one of which is your issue above. One time I was complaining that it was hard to find stack mismatches where words were leaving too many parameter on the stack or not enough. Jeff Fox weighed in (as he often would) and told me I didn't need debuggers and such, statck mismatches just showed that I couldn't count... That hit me between the eyes and I realized he was right. Balancing the stack is just a matter of counting... *and* keeping your word definitions small so that you aren't prone to miscounting. That was the real lesson, keep the definitions small.

You don't need to jump "back and forth" so much, you just need to learn to decompose the code so that each word is small enough to debug visually. It was recognized a long time ago that even in C programming that smaller is better. I don't recall the expert, but one of the programming gurus of yesteryear had a guideline that C routines should fit on a screen which was 24 lines at the time. But do people listen? No. They write large routines that are hard to debug.

Really? I have never considered data types to be a problem in Forth. Using S>D or just typing 0 to convert from single to double precision isn't so hard. You could also define words that are C like, (signed_double) and (unsigned_double), but then I don't know if this would help you since I don't understand your concern.

Yes, in terms of error checking, Forth is at the other end of the universe (almost) from Ada or VHDL (I'm pretty proficient at VHDL, not so much with Ada). I can tell you that in VHDL you spend almost as much time specifying and converting data types as you do the rest of coding. The only difference from not having the type checking is that the tool catches the "bugs" and you spend your time figuring out how to make it happy, vs. debugging the usual way. I'm not sure which is really faster. I honestly can't recall having a bug from data types in Forth, but it could have happened.

--

Rick
Reply to
rickman

Lol, so semaphores were never implemented on a machine without an atomic read modify write?

--

Rick
Reply to
rickman

You don't need a read/modify/write instruction. You need to perform a read/modify/write sequence of instructions atomically. On simple processors that could be accomplished by disabling interrupts around the critical section of code.

I don't know if there is a machine that /can't/ implement a semaphore - but that is not the question that you asked.

I suppose I could contrive one. For example, if you had a processor that required disabling interrupts as described above and you had a had to support a non-maskable interrupt...

Rob.

Reply to
Rob Doyle

I viewed the question as "why *you* can't pick Forth" - I can only really answer for myself.

You say "preferences and biases" - I say "experience and understanding" :-)

No doubt I will.

Of course, remember your own preferences and biases - I say Forth makes these things hard or difficult, but not impossible. If you are very experienced with Forth, you'll find them easier. In fact, you will forget that you ever found them hard, and can't see why it's not easy for everyone.

I can agree with that to a fair extent. Forth requires you to think in a different manner than procedural languages (just as object oriented languages, function languages, etc., all require different ways to think about the task).

My claim is that even when you do "get it", there are disadvantages and limitations to Forth.

There are times when code is complex, because the task in hand is complex, and it cannot sensibly be reduced into small parts without a lot of duplication, inefficiency, or confusing structure (the same applies to procedural programming - sometimes the best choice really is a huge switch statement). I don't want to deal with trial-and-error debugging in the hope that I've tested all cases of miscounting - I want a compiler that handles the drudge work automatically and lets me concentrate on the important things.

Don't kid yourself here - people write crap in all languages. And most programmers - of all languages - are pretty bad at it. Forth might encourage you to split up the code into small parts, but there will be people who call these "part1", "part2", "part1b", etc.

I need to easily and reliably deal with data that is 8-bit, 16-bit,

32-bit and 64-bit. Sometimes I need bit fields that are a different size. Sometimes I work with processors that have 20-bit, 24-bit or 40-bit data. I need to know exactly what I am getting, and exactly what I am doing with it. Working with a "cell" or "double cell" is not good enough - just like C "int" or "short int" is unacceptable.

If Forth has the equivalent of "uint8_t", "int_fast16_t", etc., then it could work - but as far as I know, it does not. Unless I am missing something, there is no easy way to write code that is portable between different Forth targets if cell width is different. You would have to define your own special set of words and operators, with different definitions depending on the cell size. You are no longer working in Forth, but your own little private language.

Yes, I dislike that about VHDL and Ada, though I have done little work with either. C is a bit more of a happy medium - though sometimes the extra protection you can get (but only if you want it) with C++ can be a good idea.

I use Python quite a bit - it has strong typing, but the types are dynamic. This means there is very little compile-time checking. I definitely miss that in the language - you waste a lot of time debugging by trial-and-error when a statically typed language would spot your error for you immediately.

Reply to
David Brown

I believe SVN is for the verilog, which isn't there quite yet, but the document is. Click on "Downloads" at the upper right.

Here is a link to it:

formatting link

Reply to
Eric Wallin

I can see the need for some kind of semaphore mechanism if you have one or more caches sitting between the processor and the main memory (a "memory hi erarchy") but that certainly isn't the case for my (Hive) processor, which is targeted towards small processor-centric tasks in FPGAs. Main memory is static, dual port, and connected directly to the core.

Reply to
Eric Wallin

document is. Click on "Downloads" at the upper right.

Ok, this is certainly a lot more document than is typical for CPU designs on opencores.

I'm not sure why you need to insert so much opinion of stack machines in the discussions of the paper. Some of what I have read so far is not very clear exactly what your point is and just comes off as a general bias about stack machines including those who promote them. I don't mind at all when technical shortcomings are pointed out, but I'm not excited about reading the sort of opinion shown...

"Stack machines are (perhaps somewhat inadvertently) portrayed as a panacea for all computing ills" I don't recall ever hearing anyone saying that. Certainly there are a lot of claims for stack machines, but the above is almost hyperbole.

There is a lot to digest in your document. I'll spend some time looking at it.

--

Rick
Reply to
rickman

more caches sitting between the processor and the main memory (a "memory hierarchy") but that certainly isn't the case for my (Hive) processor, which is targeted towards small processor-centric tasks in FPGAs. Main memory is static, dual port, and connected directly to the core.

Unless your system is constrained in ways you haven't mentioned...

Do you have interrupts? If so you need semaphores.

Can more than one "source" cause a memory location to be read or written within one processor instruction cycle? If so you need semaphores.

I first realised the need for atomic operations when doing hard real-time work on a 6800 (no caches, single processor) as a vacation student. Then I did some research and found out about semaphores. Atomicity could only be guaranteed by disabling interrupts for the critical operations. And if you ran two 6809s off opposite clock phases, even that wasn't sufficient.

Reply to
Tom Gardner

(snip)

(snip)

I suppose. Stack machines are pretty much out of style now. One reason is that current compiler technology has a hard time generating good code for them.

Well, stack machines, such as the Burroughs B5500, were popular when machines had a small number of registers. They could be implemented with most or all of the stack in main memory (usually magnetic core). They allow for smaller instructions, even as addressing space gets larger. (The base-displacement addressing for S/360 was also to help with addressing.)

Now, I suppose if stack machines had stayed popular, that compiler technology would have developed to use them more efficiently, but general registers, 16 or more of them, allow for flexibility in addressing that stacks make difficult.

Now, you could do like the x87, with a stack that also allows one to address any stack element. The best, and some of the worst, of both worlds.

-- glen

Reply to
glen herrmannsfeldt

Yes, one per thread.

Not sure I follow, but I'm not sure you've read the paper.

If the programmer writes the individual thread programs so that two threads never write to the same address then by definition it can't happen (unless there is a bug in the code). I probably haven't thought about this as muc h as you have, but I don't see the fundamental need for more hardware if th e programmer does his/her job.

Reply to
Eric Wallin

I used to know this stuff, but it has been a long time. I think what Tom is referring to may not apply if you don't run more than one task on a given processor. The issue is that to implement a semaphore you have to do a read-modify-write operation on a word in memory. If "anyone" else can get in the middle of your operation the semaphore can be corrupted or fails. But I'm not sure just using an interrupt means you will have problems, I think it simply means the door is open since context can be switched causing a failure in the semaphore.

But as I say, it has been a long time and there are different reasons for semaphores and different implementations.

never write to the same address then by definition it can't happen (unless there is a bug in the code). I probably haven't thought about this as much as you have, but I don't see the fundamental need for more hardware if the programmer does his/her job.

There are other resources that might be shared. Or maybe not, but if so, you need to manage it.

Wow, I never realized how much I have forgotten.

--

Rick
Reply to
rickman

I think you might be referring to the sort of stack machines used in minicomputers 30 years ago. For FPGA implementations stack CPUs are alive and kicking. Forth seems to do a pretty good job with them. What is the problem with other languages?

Yes, you *are* talking about 30 year old machines, or even 40 year old machines.

You are reading my mind! That is what I spent some time looking at this past winter. Then I got busy with work and have had to put it aside.

Eric's machine is a bit different having four stacks for each processor and allowing each one to be popped or not rather than any addressing on the stack itself. Interesting, but not so small as the two stack CPUs.

--

Rick
Reply to
rickman

(snip)

The question is related to communication between threads. If they are independent, processing independent data, then no problem. Usually they at least need to communicate with the OS (or outside world, in general), which often needs semaphores.

-- glen

Reply to
glen herrmannsfeldt

Point taken. I suppose I'm trying to spare others from wasting too much ti me and energy on canonical one and two stack machines. There just aren't e nough stacks, so unless you want to deal with the top entry or two right no w you'll be digging around, wasting both programming and real time, and get ting confused. And they automatically toss data away that you often very m uch need, so you waste more time copying it or reloading it or whatever. I spent years trying to like them, thinking the problem was me. The J proce ssor really helped break the spell.

Not saying I have all the answers, I hope the paper doesn't come across tha t way, but I do have to sell it to some degree (the paper ends with the dow n sides that I'm aware of, I'm sure there are more).

Defense exhibit A:

formatting link

Maybe I'm seeing things that aren't there, but almost every web site, paper , and book on stack machines and Forth that I've encountered has a vibe of "look at this revolutionary idea that the man has managed to keep down!" A bsolutely no down sides mentioned, so the hapless noob is left with much to o flattering of an impression. In my case this false impression was quite lasting, so I guess I've got something of an axe to grind. Perhaps I'll mo derate this in future releases of the design document.

Reply to
Eric Wallin

(snip, I wrote)

The code generators designed for register machines, such as that used by GCC or LCC, don't adapt to stack machines well.

As users of HP calculators know, given an expression with unrelated arguments, it isn't hard to evaluate using a stack. But consider that the expression might have some common subexpressions? You want to evaluate the expression, evaluating the common subexpressions only once. It is not so easy to get things into the right place on the stack, such that they are at the top at the right time.

-- glen

Reply to
glen herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.