
Helloooo! I am Moose! They/Them/He/Him I am a embedded software engineer with autism, depression and anxiaty ( Wooo! ). I post about... whatever I want... software things, mental health things... whatever I feel like Feel very wellcome to send me asks about... anything that strikes your fancy :3
266 posts
That Is A Very Neat Idea!
That is a very neat idea!
If you like things like that you might want to look into VHDL ( I learned that... some years ago, but have not touched it since ) or Verilog.
They are... programming languages for making logic gate logic.
You combine that with an FPGA, which is essentially a whole lot of NAND gates ( Which as I said, can represent any logic gate system ), and then you can make hardware... via software.
And yes, these essentially do things like your idea. Things that would take a CPU aaaaages to do, can be done very very fast. So you "just" have normal C code, but if it runs onto one of the problems it have hardware for, it uses the hardware.
This is also how graphics cards work, or just floating point operations!
It is insanely cool! :D
What is half-adder and full-adder combinational circuits?
So this question came up in the codeblr discord server, and I thought I would share my answer here too :3
First, a combinational circuit simply means a circuit where the outputs only depends on its input. ( combinational means "Combine" as in, combining the inputs to give some output )
It is a bit like a pure function. It is opposed to circuits like latches which remembers 1 bit. Their output depends on their inputs AND their state.
These circuits can be shown via their logic gates, or truth tables. I will explain using only words and the circuits, but you can look up the truth tablet for each of the circuits I talk about to help understand.

Ok, so an in the case of electronics is a circuit made with logic gates ( I... assume you know what they are... Otherwise ask and I can explain them too ) that adds 2 binary numbers, each which have only 1 character.
So one number is 1 or 0
And the other number is 1 or 0
So the possible outputs are are 0, 1 and 2.
Since you can only express from 0 to 1 with one binary number, and 0 to 3 with 2, we need to output 2 binary numbers to give the answer. So the output is 2 binary numbers
00 = 0
01 = 1
10 = 2
11 = 3 // This can never happen with a half adder. The max possible result is 2
Each character will be represented with a wire, and a wire is a 0 if it is low voltage (usually ground, or 0 volts) and a 1 if it is high voltage (Voltage depends. Can be 5 volts, 3.3, 12 or something else. )
BUT if you only use half adders, you can ONLY add 2 single character binary numbers together. Never more.
If you want to add more together, you need a full adder. This takes 3 single character binary numbers, and adds them and outputs a single 2 character number.
This means it have 3 inputs and 2 outputs.

We have 2 outputs because we need to give a result that is 0, 1, 2 or 3
Same binary as before, except now we CAN get a 11 (which is 3)
And we can chain full adders together to count as many inputs as we want.
So why ever use a half adder? Well, every logic gate cirquit can be made of NAND (Not and) gates, so we usually compare complexity in how many NAND gates it would take to make a circuit. More NAND gates needed means the circuit is slower and more expensive to make.
A half adder takes 5 NAND gates to make
A full adder takes 9 NAND gates.
So only use a full adder if you need one.
Geeks for Geeks have a page for each of the most normal basic cirquits:

I hope that made sense, and was useful :3
-
hydralisk98 reblogged this · 9 months ago
-
hydralisk98 liked this · 9 months ago
-
admitit liked this · 1 year ago
-
sweetpoetrygladiator liked this · 1 year ago
-
schlimedup reblogged this · 1 year ago
-
schlimedup liked this · 1 year ago
-
theguyrunningsouth reblogged this · 1 year ago
-
theguyrunningsouth liked this · 1 year ago
-
taperwolf reblogged this · 1 year ago
-
taperwolf liked this · 1 year ago
-
nounofrassilon liked this · 1 year ago
-
moose-mousse liked this · 1 year ago
-
noctumsolis reblogged this · 1 year ago
-
ofairandbeauteousone liked this · 1 year ago
-
commodorez reblogged this · 1 year ago
-
it-becomes-so liked this · 1 year ago
-
somniphobicfox liked this · 1 year ago
-
doctorfurbenstein liked this · 1 year ago
-
moose-mousse reblogged this · 1 year ago
-
illustrious-carbonic-eels liked this · 1 year ago
-
the-windup-official liked this · 1 year ago
-
blake447 reblogged this · 1 year ago
-
memorias-de-una-computadora reblogged this · 1 year ago
-
goldenspirits reblogged this · 1 year ago
-
goldenspirits liked this · 1 year ago
-
mbvisualarts reblogged this · 1 year ago
-
mbvisualarts liked this · 1 year ago
-
datamodel-of-disaster liked this · 1 year ago
-
unishine liked this · 1 year ago
-
vez0k1 reblogged this · 1 year ago
-
studywithvictory liked this · 1 year ago
-
arbiewebbjr liked this · 1 year ago
-
tired-goblin liked this · 1 year ago
-
cyberfolktale liked this · 1 year ago
-
quietmarie liked this · 1 year ago
More Posts from Moose-mousse
A beginners guide to GIT: Part 3 - How to learn GIT after (or instead of ) this guide
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts

Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person

Part 5: How to use GIT as a group.

First of all, GIT have a website:
And besides downloading GIT if you do not already have it, it has THE GIT book. It is honestly very good and contains quite a few translations
Second, GIT is one of the old pieces of tech. This means that it is open source, free, and that it contains its own documentation and guides.
If you are ever stuck, or confused about something in GIT, you can use the help command.
Simply writing
git help
Shows you the porcelain commands, and tells you that adding the option -a like so:
git help -a
gives you ALL commands
and the option -g gives you all the guides the manual have, like so
git help -g
If you give help another command,, it will bring you to the manual page for that command
for example, someone on the internet told you to write
git help reset --hard
and you want to know what that means before running it? Write
git help reset
And you will be shown the manual page for “reset”. Including what --hard does. (To understand the manual, you need to understand the concepts and terms from part 2.)
If you want more visual explanations, Atlassian's guides are public and also quite good (But , remember. Atlassian uses Bitbucket. Bitbucket is 99% GIT, but can still have tiny differences)
A beginners guide to GIT: Part 4 - How to use GIT as 1 person
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts

Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person

Part 5: How to use GIT as a group.

When it comes to not getting in each other's way, working alone is the simplest (It has a lot of other drawbacks). This is the simplest way to use GIT. You can do it with an external repository as a backup or just locally on your computer. It depends on how important your project is. If your laptop crashes tomorrow, which projects would you have a really hard time losing? Better to have an external backup for that. Github is often used for this (Maybe less now that Github makes machine learning AI’s, and so ARE stealing your code to train their AI on.) but you can also use Bitbucket (Which... may also steal your code...) and there are many many others out there. GIT is often used in certain patterns, called “workflows”. These have you working in more or less rigid ways to make it simple to work together. But since you are working alone, you do not risk others changing your code while you are working, so you can do it the simplest way :D
I will be doing a step by step guide that you can follow along. I will be doing it on a completely empty project and making a tiiiiiny program in C. This is because it is super simple. You do NOT have to know C to follow. You can also follow the steps with your own already existing project.
I PROMISE you, GIT cannot hurt you. Worst case scenario is that you fiddle around and break the repository part. (Meaning the files in the .git folder). But your files will always be safe.
(If you do not have git installed, check out part 3 for that)
First, I make a folder, navigate my shell into it, and call git init:

By the way, you can get used to GIT messages like this that tell you all your options, and explain what GIT has done for you. GIT is very good about giving you as much help and info as possible,
Now I will teach you the most important command in GIT.
It is more important than any other. Ready?
git status

This makes GIT tell you what git thinks is happening right now. What issues there are and what files are tracked, untracked or have been changed. Use this command often, especially while you are new to GIT, run it after every other command. It is how you learn what GIT is doing and thinking :3
Since our repo is empty it tells you what branch you are on (master. The only branch we will need since we are working alone)
and that you have not made any commits.
It also tells you the commands git think you will want to use on files. Since our repository is empty, it tells us to create some files, and then how to add them :3 So let's do that:
I have added my tiny program, as you can see:

Now let us see what GIT thinks we did:

Now, since there have been changes, git shows us them.
Files can be untracked tracked and not changed (In which case, git status does not show them) tracked and changed.
Right now, main.c is untracket. Which basically means GIT have no idea about this file, other than it is in the folder.
Ok, let us commit(save) the file. GIT tells us this is done with git add <File> . So we will write git add main.c
Then we use git status again to see what happened git status

And yeah, our file is now ready to be committed. So lets do it! git commit -m “My first commit!”
The “-m” option is to write the git update explanation directly in the console instead of using an external program to do it. Done You have now committed your code! It is now saved!
git status shows that everything in the working tree is as it was last time we committed (Duh. We JUST committed)

I will now make some changes to the main file:

Git status shows us main.c was changed...but what if we wanted to know what was changed in more detail? How will we get status to do that for us? Let us find out! git help status
git then shows the help page for status And there we can see this part:

So if we write status with 2 -v arguments, we get all the details. Let us try:

And look! It shows us EXACTLY what lines were changed! I stage the changes and commit:

And you have now learning enough about GIT to use it.. You now have all your work saved, in different commits. If you ever want to know all the commits you have made, write git log:

And if you want to know what a specific commit did, you copy the name of the commit, and write git show:

Now, everytime you want to save your work, you
1: Write/change the files you want
2: Add the files you want as part of this commit
3: make the commit These three steps are your workflow.
If you have a remote repository, then you add them steps
4: push to remote repository
To do this step, you can actually just write
git push
If you have set up a remote repository, then it just works. If you have not, then git will tell you what to do Whichever remote repository you use will tell you if you need to do other steps, like setting up passwords or ssh keys. They will also tell you how to set up the remote repository (That is not a GIT thing, that is a bitbucket or a github thing, so refer to whichever of those sites you want to use) And that is all! Every time you commit, your project is saved (it is smart to commit often, but usually only commit when your project can be compiled.) And whether you use a remote repository or not, you now have a fully valid GIT repository, and all the git tricks can be used on your project!

I love GDB (Gnu debugger). It is only useful when something have gone wrong, but GDB just makes it sooooo much easier to find the issue. The picture is of a particularly deep stack. It is a short overview of every stack-frame, and where in the code it was called from, and to what. I can also easily investigate every single stack frame alone, finding what each variable contained the moment the crash happened, what arguments each function took, and the memory position of every single element. By the way, to run this, all I did was: gdb ./build/MyAwesomeProgram run bt
If you work in C or C++, it is SUCH a handy tool to know. And it is pre-installed on basically every machine.
A beginners guide to GIT: Part 2 - Concepts and terms
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts

Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person

Part 5: How to use GIT as a group.

Now, a few (I PROMISE only a few!) concepts that are needed for being able to talk and read about GIT.
Just to be difficult, several of these have multiple names (Plø!)
GIT refers to its commands as "porcelain" commands (user friendly and clean) and "plumbing" commands (Not so user friendly, dirty). Yes. We are starting out with references to toilets :p
The workspace/working tree is all the files and folders you would have if you did not use GIT. It is folders, codefiles, headers, and build system files. All the good stuff we want to work on.
A repository is technically the hidden folder called “.git”. It is all the files GIT uses to keep track of your files and their history, and which enables you to do all the git things to the files in the working tree. You do NOT have to interact with these directly. Just know they are here ( Sometimes people refer to the working tree AND the repository together as “The repository”. Because we work hard on making life harder and more confusing than it needs to be)
The index/cache/staging area is a single, large, binary file in the .git. folder. It keeps track of the differences between last time you saved, and how the working tree is now. Every change, every new file, every file deleted.
Commit. To differentiate what GIT does from how you normally save files, we use the term “commit”. But it is just a save. Different commits are different saves. Easy peasy. Every commit, except the very first one is based on the commit before it. That is called the commits base.(This is the base that REBASE refers to).
The structure of GIT is actually very simple. It is a whole bunch of commits, and each commit knows the commit it came from (IE all commits except the first have a base). This makes a long chain. That's it. That is the entire idea
Staged files
So you now know that we can commit(save) and we have files that we change, but have not been committed. We need a name for files between those two. Files that we are getting ready to commit. All files that will be committed if you commit RIGHT NOW, are “staged for commit”.
HEAD. Because you can switch between different commits easily, we need a way to say “what commit are we looking at right now?”. That is HEAD.
HEAD can be “detached”. This basically means that the commit HEAD is pointing at, is NOT the latest commit. And while you CAN do work on a detached head, it gets messy and is not the smartest way to do it, so “detached head” also works as a bit of a warning.
(If you have ever worked with pointers, HEAD is simply a pointer to a commit)
If we make 3 commits, one after the other (which means HEAD is pointing at the last commit), then your commits could be represented like this:

Branches. These are commits that are done one after the other. You always have at least your starting branch (Usually named master or main). If you create new branches, then they start from a specific commit and can be merged into the original branch whenever you are done.
If we expand the previous example, make a branch from the first commit, and then merge it before the third commit and delete the branch, it could look something like this:
Make the branch and add to it:

Then merge it into the main branch and delete the new feature branch:

origin/upstream. This refers to what commit and branch a branch came from. In our example, the "New feature branch" would have the upstream/origin "Main branch" , "Initial commit".
Trick or treat :)
As a treat, I offer cute puppy picture!
