#Architecture Competition

1102 messages · Page 2 of 2 (latest)

narrow cypress
#

wouldn't the first byte always be at the address from the instruction pointer?

tender copper
#

No, because if the instruction has 3 prefixes, the first byte for the core decoder is 3 bytes later

narrow cypress
#

oh right

tender copper
#

(still assuming limited pipeline features)

tardy star
#

Please keep discussions relevant to the Competition

#

Generall architecture discussions are better in #computer-architecture

solemn hill
#

Oh yeah I have something I want to say here

#

I recently realised if I want to actually be able to get down and do this, I need to actually solidify my plans

#

So with that in mind, I am setting a hard 2 week deadline for suggestions

#

Past that, if you want to suggest something, I will only entertain it if it would cumulatively take less than an hour to do

#

That sound fair? Because I don't have all the time in the world, especially since I have homework to be doing in these summer holidays

tacit cave
#

Whaddya mean by suggestions, like rule changes? Level ideas?

robust sundial
#

Yeah, what exactly do you treat as a suggestion? Scoring? Levels? Rules?

blazing field
#

I actually started on my multiplier.

solemn hill
#

Something that would change how the competition would have worked

tardy star
#

This is your competition. You can always deny anything you don't want to do.

#

I don't think such a fixed timeline is going to be helpful.

#

If you want to set deadlines for yourself that's fine ofcourse

solemn hill
#

I'm just acutely aware that I recently agreed to variable bus widths, which is going to require reworking challenges I've already done and additional work for future challenges, so I want to know I'm not going to have to do much more changing

robust sundial
#

If the variable bus widths are tol much work for the gain you see in them then scrap them - it was just a suggestion

plain wind
#

I agree with Mega and micha, feel free to decline any and all suggestions, at any time. Including variable width IO buses.

tight lion
#

For what it's worth, I wasn't asking that every level allow it. Just that if we want to, we can implement it in our levels.

#

But yes, it was just a suggestion

solemn hill
#

No, I like the idea of a variable bus width for some challenges. But I guess a deadline for suggestions might be a bit much

tacit cave
#

It seems that the Calibrating Laser Cannons II level is bugged. On test 119, the original expects an output of 0. This one, however, expects an output of 39

tacit cave
robust sundial
#

The behavior of shifts has been changed in comparison to the campaign level.
Scroll up to read more

tacit cave
#

Hmm, when I implement a 4 bit mask it breaks on test 12 instead of 119

plain wind
solemn hill
#

hmmm…. I’ll see what the problem is

#

(Not now, but today)

tacit cave
# solemn hill hmmm…. I’ll see what the problem is

It's just that the pre-prepared tests in the FORMULAS array are built with the assumption that >> and << will perform a &0x3F with the operator, instead of the &0x0F you changed the automated tests to. If you'd like, I can submit a PR correcting it

solemn hill
#

That would be nice

#

The more work can be spread out the easier it is to do this competition

#

The reason I’m trying to do so little with the visible challenges is because I have to do the invisible ones all by myself

#

And there’s twice as many of those

tacit cave
#

I've got an idea I intend to submit, but I haven't put any time into learning the test format yet

solemn hill
#

Take your time if you need, there’s no deadlines and there probably won’t be for months still

robust sundial
tacit cave
#

Has anyone beat the hamming code level? It feels like the first test is expecting incorrect values but I might just not fully understand what it's wanting.

My current code gives the error in fig. 1. Checking the bit patterns of those outputs (Fig. 2), the expected pattern bears absolutely no resemblance to the source data. My understanding is that the final 31 bits of a hamming code should entirely be message bits. Shouldn't the bit pattern of the input and the expected output be the same for those last bits?

I'm pretty sure I didn't accidentally reverse the endianness of my output or anything, The bit pattern of my interpreted output in the output text matches the bit pattern in my RAM

Fig1.png Fig2.png
#

Hmm, seems that online hamming code generators agree with the level expected value

#

Wait no they don't I think I should go to bed and look at this in the morning

tacit cave
#

Got it! I'm a little confused why the overall parity bit is the most significant bit of the output... doesn't it make more sense to have it as the LSB?

image.png
tight lion
#

Nah. The normal hamming code without the overall parity bit is 63 bits, so I just used the free bit

plain wind
#

Having just completed the Hamming Code level in Symphony I'm reconsidering my original plan for a stripped down 16-bit arch. Even 32-bit would have been a decent upgrade.

tacit cave
#

Hey I did it in 8 bits just fine you'll manage

solemn hill
#

i wonder if i'll actually start fixing that level today

tacit cave
#

If you're talking about CLC2, I did submit a PR for it

solemn hill
#

I'm talking about average distance

#

The level in the debugging fork

#

Now that you bring my attention to it tho, i suppose i should merge that

tacit cave
#

I'd test it just to be sure, but it works with my solution so hopefully it's all good

solemn hill
#

I'm generally trying to do as little work as possible now, so I'll leave it up to the competitors to test it

#

Okay so since I don't feel like debugging the hash code I currently have in that broken level, does anyone have a working one I can use?

plain wind
#

I'll give it a go when it's up.

solemn hill
plain wind
solemn hill
#

Maybe, I'll read the code

#

it... looks fine to me

plain wind
# 
    let y = <U32> x + 0xfc15
    return <U16> hash16(<U32> x, <U32> 0x2ab)
}
``` should the last line have `y` not `x`?
solemn hill
#

Ah. Perhaps it should

#

There's no other reason for y to exist anyway

#

Well there's my lazy attempt to solve each of the problems you brought up

#

I have a funny feeling I shouldn't be trying to code these things all at once

#

I've synced the changes now, back to trying to find needles in a haystack

#

I am finding some logic errors at least

solemn hill
#

I've begun adding variable bus width functionality to my level base - I'll test it after this... or maybe I should just test it now before I add anything

#

Okay so my level base did have a few bad bits. I think I have jumped the gun a bit making an entire level off of it.

solemn hill
#

Base seems to be fixed now (though I only have 8 and 16 bit archs to test it with)

#

With variable bus width funcitonality too

#

Now... I suppose I try and port over

solemn hill
#

Wow variable bus width is turning out to be a pain

#

Problem is I want to send variable amounts of data too

#

And fitting that around the changing bus widths is a sure fire way to get bugs

#

It's a nice idea but I think I may lose my sanity too quickly if I continue trying to put it in as many levels as possible

#

So how about this:

#

If it's easy and makes sense to do so, I will implement variable bus width in a level

#

Otherwise, strictly 16 bits at a time

#

Anyway I'm stopping for today

plain wind
#

I think it's enough to include it in one level to showcase it.
I don't think it should be required for every level to include this feature.

solemn hill
#

Yeah, it already wasn't going to be in every level. The difference is that was a design choice and this is a sanity choice

tardy star
#

This is one of the cases where it would be useful to have a simplex library that does this kind of communication

#

I.e. it gets a byte stream from the level code and correctly sends it to the archiecture being tested

solemn hill
#

Indeed

blazing field
#

I've previously mentioned there may be levels where it's useful to put the bytestream on the SSD instead. Particularly if it might be file data in whatever RL problem you're mimicking.

polar dove
# blazing field I've previously mentioned there may be levels where it's useful to put the bytes...

(As far as I know) there is no way to pre-populate the SSD with any data with either test.si or meta.txt.

Although there exists the def ram_push(value: U8) level test API function,
which in combination with the .program_length global variable
(which is used as the write addres, it's getting incremented by that function &
it has no relation to the assembled program's length, instead it defaults to 0),
allows test.si to populate the last-placed RAM component
with data at any location, but I guess that's not ideal since likely
that component is going to be one that has the Assembler enabled.

This function is used in the Overture levels,
before one is allowed to edit the contents of the program RAM component.

polar dove
blazing field
#

Another option (on the architecture side) would be hardware buffering. Still 8 bits per tick on the input component, but you could add some hardware filling up a dedicated buffer. As long as the operation to be performed on the input is not trivial, the main CPU could be processing one chunk while the buffer is filling up with the next chunk.

#

Naturally, the designer would need to add a way to turn that off, as levels like the builtin binary_search won't work if the input is buffered.

#

But I wasn't aware SSD prepopulation was not possible.

polar dove
#

Actually, we could just assume that noone is using the top of "last_placed" RAM component,
use the def get_ram_size() Int function to calculate the data placement from the top of RAM &
just populate that section of RAM using test.si, using that function.

We have to use that function, because all addressable memory component's pointers to memory,
have their unique component ID baked-into their pointer variable names.
Otherwise we could just use the _load & _store functions to access them &
not have any issues with those components in the campaign at all.

robust sundial
blazing field
#

Or we could ask Stuffe for a function to prepopulate the SSD with. In fact, I expect we will get functions to access RAM components by name regardless.

polar dove
blazing field
#

Yeah, it's probably easier not to make assumptions right now.

solemn hill
#

Finally decided to start switching challenges to the more variable bus width

#

Just updated comp_reverse, last thing is to change meta.txt (and the architecture rules) to match

random epoch
#

Is the competition still going on?

outer crystal
#

i think technically it hasn't started yet

random epoch
#

I've got time then to go through Alpha. I was excited to get to the new stuff (beyond 1.0), and now I can also look forward to the contest challenges! I already downloaded them.

robust sundial
#

The competition isn't starting till the RAM scores are fixed, at the very least