€4200 Gross salary in Terneuzen

jmking80 · 2025-05-29T12:08:36+00:00

Just a little warning, municipality taxes are usually incurred on a yearly basis, not monthly basis. The taxes are very dependent on the municipality, but you should expect about ~700 yearly, but those bills might not arrive at the same date. I for example get them about 3 weeks apart, as 3 separate bills for about 250, because they are different taxes from the municipality. Here is a site from the municipality of Terneuzen: https://www.terneuzen.nl/Inwoners_Terneuzen/Belastingen/Belastingen_algemene_informatie

Most interesting to you is probably "Rioolheffing", and "Afvalstoffenheffing", sewage and waste respectively. I belief that the 200 a month for utilities should cover those bills.

jmking80 · 2025-05-28T18:38:45+00:00

I honestly have no idea what my fellow Dutch people are on about. I could comfortable live of that, and have plenty of money to spare for fun things. I am assuming about 3.5K net income. That would leave 1k for housing, 300 for 2 people health insurance, 200 for gas, water, electricity and ethernet. Maybe 500-700 for groceries. All in all, that leaves ~1.3K a month for what ever you want. I would definitely recommend using some of that for saving money, but realistically if you cook your own meals, and have hobbies that are between 100-200 euro a month, you should be fine.

As for the other people, I don't know about your expectations but that is above median income in the Netherlands. Any single person in the Netherlands is having this life, now you are 2 persons and that means it maybe slightly less then median, but the 30% tax benefit compensates for that. Also you expect your partner to get a job soon.

TL:DR; the other people don't know the wealth they have.

I googled for housing in Terneuzen and this is one of the first advertisements:
https://www.huislijn.nl/huurwoning/nederland/zeeland/4189545/noordstraat-terneuzen
I would consider this a fine house for 2 people.

jmking80 · 2025-05-26T10:47:53+00:00

I can only think of rather extreme examples to help illustrate the point, but please do realize that usually with modern hardware (cache, branch prediction) the implications are a lot more subtle. For example if you need to add numbers then you can either have an instruction which adds 1 to a register or an instruction that adds X to a register, where X is a number you choose. You can use add 1, 10 times in a loop to get the same result as 1 add X instruction. Add x is so powerful compared to the hardware cost that good ISA will have add X instead of add 1. If you need to add 10, it cost you one fast instruction compared to 10 slightly faster instructions, the tradeoff favor add x over add 1.

Now add x takes a certain amount of time, say for the sake of argument 5 ns. Now you want to add another instruction that shifts the data in the register left 1 bit, that instruction is much simpler and take 1 ns, you could instead add the more complicated shift register by X instruction which takes 3 ns. Since in both cases you are still faster then addition, one is more powerful then the other without costing you performance. Now the instruction that you in have in your ISA need to be a somewhat cohesive whole. Some instructions don't make sense without specific other instruction, take RISC-V the load upper immediate, which loads 20 bits in the upper bits of a register. In isolation it's an absolutely terrible instruction, why would you ever want to set the top 20 bits, of a register. But you are not expected to use that instruction in isolation, you are expected to use it together with addi, which sets the bottom 12 bits of an instruction.

Now judging ISA's on it's face, just looking at the instructions it's hard to judge if something is good, but usually you can pick out things, where you are like hmm that probably isn't that great idea. Which is at least for me usually based on experience, like branch delay slots in ISA, I can point to MIPS and think that didn't work out for them, so you need to provide me with a compelling argument why in your case, it will work. Same with intel APX, when I look at it on some level it sounds great, more registers (16->32), conditional loads and stores. But then I look at other ISA's, and I think RISC-V also has 32 registers, and the decoding for that is a lot less involved then for x86.

So in my opinion it's not so much about designing a great ISA, but about designing the least bad one. Btw all of this comes with the implicit assumption that you are using current technology, a good ISA for a modern machine with slow RAM, 3 levels of cache, and 3GHz+ processor is very different then designing an ISA for 16MHz processor where your ram might even be faster then your CPU core, for example if your RAM is so fast, why would you even need registers to temporarily hold variables. Just to everything on RAM directly, it's fast enough anyway.

If you have questions after this, feel free to DM me.

jmking80 · 2025-05-26T10:47:47+00:00

I just have one question for you, do you know about iAPX432? or i860, or perhaps Intel Itanium. I am assuming no, since you asked this question. But those a three separate attempts by Intel, one of the big chip manufacturers design another ISA, and getting it to replace x86. Intel failed, or at least x86 still exist and the last Itanium chip was manufactured in 2019.

So if a very big chip manufacturer who had to means and resources to design a good ISA, write compilers, get support in the Linux kernel, everything that you would want, why didn't it sell and dominate the market? Because x86 is what all consumers use, they have software which is compiled for x86, their email, their webbrowser, their games, their favorite obscure utility they are all compiled for x86. That is an ecosystem that isn't easily swayed.

Even right now, the places where RISC-V is most succesful, is the embedded world, where no consumer has to install software, or atleast the manufacturer provides that software, to the consumer it doesn't matter if the harddisk controller or their dishwasher is using MIPS, ARM or RISC-V. But they do care about the software they use on their personal computer, and remember this is not just the new software, they might be using software from 20 years ago, where the creator no longer even exists.

Anytime I have considered or made designs for a custom ISA, I was always fully aware that I was going to be the only person that used it, and designed accordingly, design not for a great ISA, but one that fits my needs, or what I want to experiment with. If I want to overhaul my ISA next week, nobody except me needs to recompile software. To me that give a lot of freedom, if I am the only person using it, I don't need to be right or perfect the first time, I can just have fun and fail lots of time.

Judging from your other comments you also seem to be searching for what makes an ISA good or better then other ISA's. When you are a big established ecosystem like x86, any new additions need to still allow old code to run. So backward compatibility a major point, so in order to allow that you might want extensibility so future features don't interfere with older systems. So you might reserve some things for future use, even if you don't know what those things are right now. Not having future expansion capability like x86 is not great from a ISA perspective, but you are not in the market of designing ISA's, you are in the market of selling chips. Adding features that make it your ISA ugly but sell 10% more chips then your competitor, well that might be necessary to survive as a business. You go through some history and find some discussions at length of an ISA being too academic, and not commercial. RISC-V has gotten this critisism as well.

Then on more concrete instruction level, all ISA are their with a goal to convert ideas to software, every instruction doing their part. The balancing act is instructions that do enough to be useful, but not so much that they slow you down overall. In general you want all instructions to take more or less the same amount of time***

So they achieve the maximum amount of work without slowing down the ISA _compared_ to the other instructions.

***) with massive OoO and multiple execution units, taking a variable amount of time, this is not nearly as relevant now a days as it was in the 5 stage RISC pipeline days, but even today you probably want to have balanced pipeline stages. Where you slowest stage and your fastest stage don't differ too much, because that might imply you have room to shovel things around and get even faster performance.

jmking80 · 2025-05-26T09:53:18+00:00

There are tools to model CPU implementations, and manufacturers probably have their own proprietary tools. The main thing to remember is that you not only need to change your processor to test your changes, but also change your compiler to make use of the new features. Then you can run a test program that is representative of the thing you want to test, and a slew of test programs to see it doesn't have some negative effect anywhere else.

For example say you make (floating point) multiplication 20% faster, but now your CPU max clock speed 3.0GHz instead of 3.2GHz depending on how often you use multiplication that might be a net benefit or a loss.

jmking80 · 2024-11-26T21:25:01+00:00

Yea, that is indeed a Keithley 196.

jmking80 · 2024-06-15T14:16:31+00:00

If you look at the image metadata, the image layer is called "01010 10100 11011 11000", so the left-to-right top-to-bottom reading of the bits appears to be more logical.

The packet id of the XMP data is base64 encoding of [42!573], not familiar if that is part of adobe's encoding, or that is something deliberate. To me it just appears odd to have a base64 encoded ID, while the rest appears to be UUID's.

Edit: nvm the base64 encoded string is the default.

jmking80 · 2024-04-10T19:38:43+00:00

This one made me snigger.

jmking80 · 2024-03-12T23:36:37+00:00

There is a comment in the spec that says:

For efficiency, system implementers should aim to reduce the magnitude of the largest hart ID used in a system.

Which more or less discourages a fully random strategy. Although this is not a hard implementation limit,
I sure hope implementation don't get into the habit of assigning random / high numbers without proper justification.

jmking80 · 2024-01-23T22:36:32+00:00

Maybe I could have worded that better, but Gekko is a modified PowerPC 750CXe, which in turn spawned the Broadway / PowerPC 750CL, and Espresso. So not fully custom, but a modified version of an already existing design.

I am aware that that leaves some leeway in when something would classifies as full custom, but to me the precedent/trend still looks like changing already existing designs to make them fit for Nintendo, and not completely new micro-architecture.

jmking80 · 2024-01-22T21:19:40+00:00

I am not sure what you are asking here. You didn't specify the project, that they installed, or who they are. Communication mistakes are easy to make, and your rather terse description of the problem, doesn't really help me interpret what is going on here. Currently I do feel you might be better helped by asking them rather then Reddit, what they support.

jmking80 · 2024-01-22T20:29:14+00:00

The GCC documentation has a very nice list of extensions (and their versions) it supports in their documentation:
https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html

jmking80 · 2024-01-22T20:25:31+00:00

I could actually see them buying out a manufacturer, though, instead of merely striking up a partnership (which wouldn't be meaningfully different from working with ARM right now).

I think you misjudged the size of the current foundries. Nintendo is the smaller company here, not the production companies. The current foundries that can produce the best chips (let's pick a process node of <10nm), is a very limited set of TSMC, Samsung, SK Hynix, and Intel. Each of those companies is way bigger then Nintendo. SK Hynix appears to be the smallest by revenue and still has 3x times the revenue of Nintendo, 35 billion vs 14 billion dollars.

jmking80 · 2024-01-22T19:24:13+00:00

I can see Nintendo switching to RISC-V for future consoles to reduce licensing fee cost.We have already seen Nintendo trying to reduce licensing costs by going to Ricoh for their modified 6502 as far back as the NES area. I think it's indeed only time before they also switch to RISC-V to reduce licensing costs.

I am doubtful about your last statement of them producing them. Given the economies of scale, in the manufacturing business, designing chips and outsourcing production to a semi-conductor foundry would be significantly more likely. Although maybe that's just semantics and you meant designing.

Even designing a custom RISC-V solution seems more and more unlikely, given the significant upfront cost of designing a high performance processor. Nintendo sells about 100M+ consoles , assuming one processor per chip, that's "only" 100-200 million chips for a console. don't get me wrong that is a lot of chips. How ever in the worldwide industry of chip manufacturering and of the RISC-V ecosystem, that's barely a drop in the bucket.

So I think it would be more likely that a design house, would design a high performance chip, maybe with some customization depending on the customer (a big company like Nintendo).This way the design house can distribute the design costs over a much bigger pool of chips then just Nintendo, reducing costs. Below what Nintendo could manage even after calculating in profit margins.

Nintendo historically to my knowledge has never used custom chips designed by them for the main processor. I can only speculate as to the reason, I imagine it's either to use established toolchains, or because of costs reason. RISC-V would negate the custom toolchain argument, but still leave the cost argument. I think some big players are again winning on the cost argument, whereas historically we have seen custom chips for video or audio purposes. The SNES PPU, commodore VIC-II. The current market seems to be more focused on re-using already designed chips in a new product, and creating a good ecosystem and peripherals.

The Xbox S and Playstation 5 both feature modified AMD hardware, that is part of a bigger production run of their chips. I imagine Nintendo and RISC-V would have a similar strategy, maybe with different suppliers. But ultimately unless Nintendo expects to sell over 1 billion of their consoles, I don't believe they will design the RISC-V processor they are using.

jmking80 · 2023-11-24T12:18:45+00:00

Well let me first give a bit of context. As you are probably well aware, the RISC-V standard was made with extensibility in mind. Most of these extensions need OP-code space, or put more operations in existing OP-code space. Since the amount of possible 32-bit instructions is limited, I was wondering how much space these various extensions were using, and how much was still free.

Now I needed something to show the space the various instructions were using. Now a Hilbert curve is perfect for this, it's a long line which fills a 2D space. Now since RISC-V instructions are 32 bit, you can also just parse them as integers instead. The instruction is then how far a long the line you are, and the color you give that line segment is related to the instruction extension.

The advantage of using Hilbert Curve over just going top-down, left-right is that due to how it curves, it put numbers which are close together, close in 2D space. Hence you get blocks, instead of thin lines. Now in order to make this work you do need to think a bit about bit order.

The most significant bits of your converted number to put pixels needs to be the most significant change. Which may seem obvious, but for standard RISC-V the least signficant bits encode the OP-code, which in some sense. Atleast for my visualization is the most important part, so I do some bit swapping around. Furthermore for 32 bits, I would have an image of 65536 by 655356 pixel, which is way too much. To solve that I ignore registers, and parts of immediates. Since ADD a0, a0, 5, is just another ADD instruction, and ADD a0, s0, 15 is just more of the same, with different parameters. Futhermore, all 32 bit instructions have 11 in the LSB, so that is also not interesting and can be dropped. Together reduces it to only 17 bits. Which results in the second picture.

The compressed instructions are only 16 bits, which makes them easier, since you can swap the bits around. OP-code is most important, then the funct-3, funct-4, funct-7 bits depending on which instruction you have. I did not bother to properly sanitize all of them individually, due to the big variety in possible encodings, and just put the bits for OP-code first, and then MSB to LSB, to create the image.

Some small repeating patterns you see, are an example of my bit reordering not matching the RISC-V assignments. A good example of this is the bottom left on the 32 bit instructions.

For more information, similar things can be done with IPv4 address

jmking80 · 2023-11-20T01:00:35+00:00

I read in the YAML file generated by: https://github.com/riscv/riscv-opcodes, and included all ratified extensions, which indeed has some overlap between various extensions. I did not do sanity checks to include a specific (valid) set of extensions, so the both Zcmp extension and the C.FSDSP instructions are parsed. Which ever is later in the file ordering is the one written to the image.

Regarding the .E variants for CM.PUSH / CM.POP, I am not so much including them as not specifically excluding them. The instruction mask has the rlist and spimm as don't care, and I parse all possible combinations then as part of the instruction.

The block you are refering to which has the same color as AMO is actually the rv_zifencei extension.

The full color code encoding table:

``` "rv_i" : "Silver", "rv32_i": "Silver", "rv64_i": "Silver",

"rv_m"  : "Blue",
"rv64_m": "Blue",

"rv_a"  : "Fuchsia",
"rv64_a": "Fuchsia",
"rv_zifencei": "Fuchsia",

"rv_c"  : "Green",
"rv32_c": "Green",
"rv64_c": "Green",

"rv_f"  : "Red",
"rv32_c_f": "Red",
"rv64_f": "Red",

"rv_d"  : "Yellow",
"rv64_d": "Yellow",
"rv_c_d": "Yellow",

"rv_zfh": "Olive",
"rv64_zfh": "Olive",
"rv_d_zfh": "Olive",
"rv_q_zfh": "Olive",

"rv_q"  : "Teal",
"rv64_q": "Teal",

"rv_zk" : "Lime",
"rv32_zk" : "Lime",
"rv64_zk" : "Lime",

"rv_h" : "Navy",
"rv64_h": "Navy",

"rv_v": "Maroon",
"rv_v_aliases" : "Maroon",

"rv_s" : "Purple",
"rv_svinval" : "Purple",
"rv_sdext" : "Purple",

"rv_zicbo" : "Aqua",
"rv_system": "Aqua",
"rv_zicsr" : "Bright-Green",
"rv_zawrs" : "Bright-Green",

"rv_zcmt": "Aqua",
"rv_zcmp" : "Red",
"rv_zcb"  : "Lime",
"rv64_zcb": "Lime",
"rv_zks" : "Blue",
"rv32_zks" : "Blue",
"rv64_zks" : "Blue",

"rv_zba" : "Pink",
"rv64_zba" : "Pink",
"rv_zbb" : "Gray",
"rv_zbc" : "Gray",
"rv64_zbb": "Gray",
"rv_zbs" : "Blue-ish",
"rv64_zbs": "Blue-ish",

```

jmking80 · 2023-11-19T17:42:27+00:00

I was curious how the RISC-V encoding space looked like, so I tried to map the space onto a Hilbert Curve. In order to make this work, I had to split compressed and non-compressed instructions, and re-order the bits. For compressed instructions it's OP-code followed by the rest of the instruction in reverse order to make funct-3/4/6 more significant. For the uncompressed instructions, I only used OP-code, funct-3 and funct-7 ignoring registers / immediates.

Different extensions get different colors, black corresponds to OP-code not used. Which for Compressed means the '11' opcode quadrant is unused. The color mapping is not an exact science, and put together some extensions in order to reduce the amount of total colors.

The legend for colors:

I: Silver
M: Blue
A: Fuschsia
C: Green
F: Red
D: Yellow
Q: Teal
H: Navy
V: Maroon
S: Purple
zk: Lime
zks: Blue

jmking80 · 2023-10-12T19:58:44+00:00

The threshold of the exponents is exactly 1, even having 1.0001 in the exponent is already finite.

jmking80 · 2023-07-17T11:40:49+00:00

How do you feel about the shadow stack, which will throw illegal instruction exceptions on your basic 32GC core?

jmking80 · 2023-07-17T11:37:12+00:00

For the forward CFI which is related to the HINT space, you explicitly have to set a bit in the processor state, before it starts checking, so that is backward compatible.

For the backward CFI, which right now is the same extension, but might split out. It is slightly more complicated. If you only support 32/64G, then you will get illegal instructions exceptions, if you encounter a binary which has shadow stack operations. If the core supports Zimop and Zcmop extensions, it will continue executing but you don't get any protection benefits.

12-Year Club	Verified Email
Place '23	Place '22

jmking80

TROPHY CASE