Hacker News new | past | comments | ask | show | jobs | submit login

That code in the figure is an old code, honestly it's an old screenshot that I don't even remember what it corresponds to, but your analysis is basically correct, even though I used absolute addresses before while now everything is relative to the current address. I'll try to answer a bit of everything:

- yes, R0 is constantly set to 0. - ANYI is a ternary function (ANY) that uses an immediate (ANYI). It does nothing but load the immediate value into the register indicated as the first operand. - Yes, it is a balanced ternary, and clearly negative addresses are correctly interpreted

>out 50(r0) r2 ;output on console0? out 60(r0) r2 ;output on console1?

- Exactly. 50 and 60 are the addresses of the two serial ports on the motherboard.

- R26 is the return register set by JSR

-Addressing is at tryte level and an instruction is always 4 trytes long. You are right that it seems a bit strange, but it is a compromise that I had to accept and that I think was the best solution to implement. (I am happy to note that your doubt was also our strong doubt during the design phase, it means that we are considering the same problems...)

-There are the dimensions of the data to operate on as a suffix of the instructions (like on motorola 68000) for which there is an LD.T (load tryte), LD.S (load short) and LD.W (load a whole word of 24 tries). There are also instructions that load/save by addressing the memory as if it were a stack for example PUSH.W (R20),R4

>Even again each instruction is 4 tries, so we could eliminate the low bits and >move... oh, I forgot that it is ternary, it does not matter. You think I didn't think about it? ;)

- The IO space is separate, in the end it cost me almost nothing and I did it.

The RISC features that I have kept are essentially 2: - Constant instruction length - Memory access only with Load/Store

In fact among the RISC things that I could remove in a future version are precisely the single access to memory only with LD/ST, it is true that it is a main feature of RISC, but it is also true that it could be a problem for code density. But it is something that I will see on the 48-trit architecture

>This may sound harsh, but to me the architecture looks both fairly conventional, and at the same time like a bit of a mess, which would be fine for a hobby project, but not for something with a website making grandiose claims and clearly intending to be a commercial product.

-That it is "conventional" ok, (even if none of the conventional architectures are ternary, but whatever...) that it is messy, what do you mean? The website says what the project actually is. I'm glad they are grandiose things, but that's it. And yes, we want to become a commercial product soon. If you have suggestions or other specific questions, I'm here to answer you ;)






If there's a LD.T instruction, it would've been the obvious choice to use that to load a character, instead of wasting an entire word on each. But maybe it didn't exist yet when that code was written.

The console I/O also seems to be dependent on external hardware to delay until the last character has been actually sent, or maybe your prototype was clocked slow enough that this wasn't necessary?

So, if the external data bus is always 24 trits, however addressing is in units of 6 trits, how does the hardware (CPU->memory interface) handle that? Is the address bus using binary instead of ternary?

What I meant by "conventional" is that other than using base 3, it isn't that different from other computer architectures, certainly not the idea you describe in the OP (that must have come later, since it isn't mentioned at all on your website). Some ternary operations might be useful for neural nets, but that wouldn't be an application for a general-purpose processor like this.

And some of the "messiness" might have been fixed, but again, there is absolutely no specification of what this architecture is supposed to be, so I was going from the one snippet of code that you have made public. And maybe you're still making changes, or do you intend to market a commercial microprocessor with absolutely no published specification?


Yes, of course to load a character I use LD.T

Uhmm..actually the OUT instruction ends immediately after its normal cycle. the character is sent to the mainboard that reads it and puts it in a buffer and passes from a buffer. (it's more complex, if you want we can discuss)

The external BUS is 24 trit. the motherboard converts it by encoding it into binary and the data is stored on 48bit RAM. We don't have native ternary RAM yet unfortunately, but it was the only way to have some memory and use the processor.

I don't quite understand what idea I describe in the OP you're referring to. And I don't understand what ternary operations might be useful for neural networks (we've had contact with Korean researchers asking about this processor for neural networks).

The specifications obviously exist, but I don't think it's a good idea to put them here on a generic site! I think the marketing phase will take a while longer and as you may have read on the site, we're still fixing things here and there and we need a marketing apparatus.


The comment/question about OUT was more speculation on how it worked on the prototype. But maybe this buffer is part of the architecture, in which case you'd have to consider what happens if it get completely filled (could happen easily with just a few MHz CPU, at standard serial port speeds).

Re. memory: of course with no ternary RAM, you have to somehow encode the trits into bits. But I was more curious about the address bus. So if your memory is organized like this:

    --- word #0
    --0
    --+
    -0-
    -00 word #1
    -0+
    -+-
    -+0
    -++ word #2
how does that map to binary addresses for the RAM chip(s)? What if you had ternary RAM, would that change how you address it? Does address --0 map to the second lowest/highest (depending on endianness) tryte in word #0, or something entirely different?

Maybe you thought about this a lot more than I have and figured out an ingenious solution. But I would have either gone with word addresses, or power-of-3 units.

And how all of this ties into non-Von Neumann architectures, I still have no clue.


Yes, the serial buffer is included in the motherboard. The problem is not so much for OUT but for IN, if the buffer fills up.

As for the bus addresses, the counter program starts from the lowest address. The mainboard obviously knows how much RAM is present and performs a translation to the first available low address. Nothing transcendental.

I did not understand the connection with VonNeumann architectures, this is a classic vonneumann architecture, only that the information is in base 3...

Anyway you seem to be really very expert, certainly more than me (I am mainly a programmer and I had to learn these things at low level practically by myself), you could actively help the project...


In your OP, you wrote that this ternary computer is really a "first step" towards a completely different dataflow-based architecture. The main page of your website proclaims some sort of revolutionary "Third Millenium Computing", with applications to AI and "research on algorithms", whatever that is supposed to mean.

>The mainboard obviously knows how much RAM is present and performs a translation to the first available low address.

How exactly is this done in hardware? I can't figure it out, so you must be the expert on that. Unless it's like a separate microcontroller doing div/mod in a loop to convert between the bases for every memory access, it couldn't be that, right? Right?


Ok, maybe that's not clear, probably my not-so-perfect English is a problem. The dataflow architecture was the initial idea. What I'm talking about now is the ternary processor, a normal VonNeumann processor with ternary data and ternary arithmetic. This may eventually form the basis for the dataflow processor, but right now I'm talking about and building the ternary processor (Of course dataflow architectures are quite different and unconventional, but that's in the future, I'm not talking about it now).

As for address management, as I said the mainboard does it all, but I didn't care to go that low in detail, it's all a simple VHDL function in an FPGA. It already comes to the FPGA in "ternary encoded bunary" from external circuits.


While not quite as terrible as my first idea, I suspect this simple function expands into much more logic than is reasonable, both in terms of size and propagation delay - the rest of the system is just small and low speed enough that you don't notice it.

The way I see it, cool hobby project, except you've already created a website promising next generation AI supercomputer chips, and then basically admit that you don't even know what goes on at the level of logic gates. And seem to avoid giving any technical details at all.

Designing a high-performance CPU is difficult enough to do in conventional binary logic, and is generally done by teams of people who know much more than you or I about all sorts of details on how to pipeline instruction execution efficiently, with branch prediction and speculative execution etc., and also the constraints imposed by manufacturing processes and physics itself.

You can't just assume someone can magically turn your ideas into such a CPU. And if they could, they could probably do it without you and whatever intellectual property you seem to be wanting to keep secret. Also, ternary being considered more efficient in some mathematical way doesn't necessarily mean an actual hardware implementation will be similarly efficient.


ok, now i can say for sure, you didn't read the site well at all. you didn't even read my answers well. maybe you would have understood that now mosfet level design is already happening but it only concerns the CPU (if you want to deal with the mainboard, fine, you will have read that it is open hardware). I don't understand what you need such low level technical details for, it is obvious that i am not here to share them. If you want to make a CPU do it too, in the end we will see who did it better. now excuse me I have some serious work to do.

Maybe it's a problem with my reading comprehension (or my web browser), but there seems to be no information about this open hardware - or really anything technical, other than the CPUs bus width and register count -, on your site or forum?



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: