Comment

Comment on Analog computing is undergoing a resurgence

A CPU is a very complex gate array which handles bothersome tasks such as synchronization (run conditions) and memory access, and presents you with a very limited set of instructions. All serial programming builds upon this very limited set of instructions, and the instructions have been thoroughly tested over the past 6 decades.

Not to say that CPU architecture or microcode is fail-safe, but the chance of your computer blue-screening because of a failure of your CPU is rather small.

Now, parallel programming (the low level variant, not the hijacked definition) is the art of “wiring” those gate arrays manually. A CPU is actually made using parallel programming, so all the safeties it presents for serial programming will not be present in parallel programming, as parallel programming does not use a CPU.

source

Sort:hotnew top

elbarto777@lemmy.world ⁨1⁩ ⁨year⁩ ago
You lost me at parallel programming not using a CPU.

Perhaps you mean that it uses the lower levels of the CPU.

source
- ekky43@lemmy.dbzer0.com ⁨1⁩ ⁨year⁩ ago
  I think you are misunderstanding me. Are you perhaps thinking about multithreading or multi core? Because some people have also started calling that “parallel”, even if it is nothing like low-level parallel.
  
  A CPU does not build upon a CPU, a CPU builds upon a transistors which are collected into gates, and which can be assembled into the correct order using parallel programming.
  
  source
  - elbarto777@lemmy.world ⁨1⁩ ⁨year⁩ ago
    I understand all that. I wrote my first 6502 assembler program in 1989 - and it was fun, by the way!
    
    I am also aware that today’s CPUs are nothing like the 8-bit CPUs of the 80s. So we’re on the same page in that respect.
    
    I understand what you’re saying now. You’re talking about programmable gate arrays, which is cool. But I still don’t understand how “parallel programming” gate arrays comes with almost no safety compared to “serial programming” gate arrays. If you are not careful in either mode, you can introduce serious bugs in the programming.
    
    source
    ekky43@lemmy.dbzer0.com ⁨1⁩ ⁨year⁩ ago
    Right, apologies for dumping it down so far, I find it hard to properly gauge the knowledge of others on the internet, and just try and play safe.
    
    I wasn’t aware that one could serial program gate arrays, as, as far as I know, the definition of serial programming is code that is governed by a processor, and which prohibits anything but serial execution of commands. So it’s new to me that gate arrays can run serial code without any governance or serialization process, since gate arrays by themselves are anything but serial. Or rather, that you need to synchronize anything and everything that is supposed to be serial by yourself, or use pre-built and pre-synced blocks, I guess.
    
    Anyway, going by the definition that serial programming can only be performed using some kind of governance or synchronizing authority, that alone would be another layer of security.
    
    As serial implies, it rid us, or lessened the burden, of those timing related issues, some of which included:
    
    All the problems of accessing in-use resources that multi-cored serial “parallel” programming reintroduced.
    
    Making a block and not properly timing it resulting in the clock changing while it’s still flipping gates and produce unexpected behavior.
    
    As the above, just generally having to time everything, as having too many clock blocks or sync checks results in unnecessary speed loss, and having too few checks might result in unexpected behavior.
    
    Over/underclocking and other slight power and clock variations.
    
    Uninitialized gates producing random behavior.
    
    And by extension: the power up process not being exactly the same every time, resulting in more unexpected behavior. Very annoying to debug when it looks all right to start with.
    
    Reading through seconds of timing diagrams (that’s a lot of reading with a clock time of nano seconds).
    
    Block placement and connection problems.
    
    Using gate array layouts/code with differing transistor specs.
    
    And the list goes on, but you know.
    
    Serial also has a lot of pitfalls, and you can definitely screw things up bad, but at least you don’t have to think much about clock or timing, or memory placement, unless communicating between devices or cores, and those sync problems tend to be rather tame and simple compared to intra-processor problems.
    
    At least from my experience.
    
    source
    -> View More Comments