ਜਾਣੋ ਕਿ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਵਿਚਾਰ—ਅਕਸਰ John von Neumann ਨਾਲ ਜੁੜਿਆ—ਕਿਵੇਂ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਸਾਫਟਵੇਅਰ, ਜਨਰਲ-ਪਪਰਪਸ ਕੰਪਿਊਟਰ ਅਤੇ ਆਧੁਨਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨੂੰ ਯੋਗ ਬਣਾਇਆ।

ਆਧੁਨਿਕ ਕੰਪਿਊਟਿੰਗ ਦੇ ਕੇਂਦਰ ਵਿੱਚ ਇਕ ਸਧਾਰਨ ਸਵਾਲ ਹੈ: ਇੱਕ ਹੀ ਮਸ਼ੀਨ ਨੂੰ ਹਰ ਵਾਰੀ ਦੁਬਾਰਾ ਬਣਾਏ ਬਿਨਾਂ ਕਿਵੇਂ ਵੱਖ-ਵੱਖ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਇਆ ਗਿਆ? ਸ਼ੁਰੂਆਤੀ ਇਲੈਕਟ੍ਰਾਨਿਕ ਕੰਪਿਊਟਰ ਤੇਜ਼ ਹਿਸਾਬ ਲਗਾ ਸਕਦੇ ਸਨ, ਪਰ “ਕਾਮ ਬਦਲਣਾ” ਅਕਸਰ ਮਸ਼ੀਨ ਦੀ ਭੌਤਿਕ ਵਿਵਸਥਾ ਨੂੰ ਬਦਲਣ ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਸੀ। ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਵਿਚਾਰ ਉਹ ਮੋੜ ਸੀ ਜਿਸ ਨੇ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ ਬਣਾਇਆ।
ਇੱਕ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਉਹ ਮਸ਼ੀਨ ਹੈ ਜੋ ਕੰਮ ਦੀਆਂ ਹਦਾਇਤਾਂ (ਪ੍ਰੋਗਰਾਮ) ਨੂੰ ਉਸੇ ਕਿਸਮ ਦੀ ਅੰਦਰੂਨੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਡਾਟਾ ਵੀ ਰੱਖਦਾ ਹੈ ਜਿਸ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਕੰਮ ਕਰਦਾ ਹੈ। ਹਾਰਡਵੇਅਰ ਨੂੰ ਦੁਬਾਰਾ ਵਾਇਰ ਕਰਨ ਜਾਂ ਪੈਨਲ ਆਪ-ਹੱਥ ਨਾ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਨਵਾਂ ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਸੈਟ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਵੱਖਰਾ ਕੰਮ ਚਲਾ ਸਕਦੇ ਹੋ।
ਹਾਲਾਂਕਿ ਹੁਣ ਇਹ ਆਮ ਗੱਲ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਡੂੰਘਾ ਬਦਲਾਵ ਸੀ:
ਇਹ ਸਿਰਫ਼ ਇਤਿਹਾਸਕ ਦਿਲਚਸਪੀ ਨਹੀਂ ਹੈ। ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਧਾਰਨਾ ਇਹ ਸਮਝਾਉਂਦੀ ਹੈ ਕਿ “ਸਾਫਟਵੇਅਰ” ਕਿਉਂ ਹਾਰਡਵੇਅਰ ਤੋਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ ਕਿਸੇ ਡਿਵਾਈਸ ਨੂੰ ਅੱਪਡੇਟ ਕਰਕੇ ਨਵੇਂ ਫੀਚਰ ਖੋਲ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਚਿਪਸ ਨੂੰ ਬਦਲੇ।
ਹੇਠਾਂ ਵਾਲੇ ਸੈਕਸ਼ਨਾਂ ਵਿੱਚ ਅਸੀਂ ਪ੍ਰਾਰੰਭਿਕ ਸਮੱਸਿਆ, ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਪਹੁੰਚ ਨੇ ਕੀ ਬਦਲਿਆ, ਉਹ ਲੋਕ ਅਤੇ ਦਸਤਾਵੇਜ਼ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ mashhoor EDVAC ਰਿਪੋਰਟ ਸ਼ਾਮِل ਹੈ) ਜਿਨ੍ਹਾਂ ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਸਪਸ਼ਟ ਕੀਤਾ, ਅਤੇ ਕਿਵੇਂ “von Neumann architecture” ਨਾਮ ਇੱਕ ਵਿਆਪਕ ਡਿਜ਼ਾਈਨ ਲਈ ਪ੍ਰਤੀਕ ਬਣ ਗਿਆ — ਇਹ ਸਭ ਚਰਚਾ ਕਰਾਂਗੇ।
ਹਾਲਾਂਕਿ John von Neumann ਦਾ ਨਾਮ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਿੰਗ ਨਾਲ ਕੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਸਲਾਹ-ਮਸ਼ਵਰੇ ਵਾਲੇ ਇੱਕ ਗਰੁੱਪ ਅਤੇ ਸਮੇਂ ਦੀ ਪਹਿਲ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਖੋਜਕਰਤਾ ਇਕੱਠੇ ਇਹੇਵੀਂ ਵਿਚਾਰਾਂ ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਸਨ ਜਦੋਂ ਪਹਿਲੇ ਵਰਤੋਂਯੋਗ ਇਲੈਕਟ੍ਰਾਨਿਕ ਕੰਪਿਊਟਰ ਬਣ ਰਹੇ ਸਨ। ਇਸ ਲੇਖ ਵਿੱਚ ਉਹ ਸੰਦਰਭ ਦਿੱਤਾ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਟੀਮ-ਚੱਲਣ ਵਾਲੀ ਕੋਸ਼ਿਸ਼ ਸਮਝਣ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਵਿਚਾਰ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਿਆ ਅਤੇ ਪ੍ਰਮੁੱਖ ਮਾਡਲ ਬਣ ਗਿਆ।
ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਵਿਚਾਰ ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੇ ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਅਜਿਹੇ ਨਹੀਂ ਸੀ ਜਿਵੇਂ ਅਸੀਂ ਹੁਣ “ਸਾਫਟਵੇਅਰ ਚਲਾਉਣਾ” ਕਹਿੰਦੇ ਹਾਂ। ਉਹ ਤੇਜ਼ ਗਣਨਾ ਕਰ ਸਕਦੇ ਸਨ, ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਵਾਉਣਾ ਹੈ ਦੱਸਣਾ ਅਕਸਰ ਮਸ਼ੀਨ ਦੀ ਭੌਤਿਕ ਵਿਵਸਥਾ ਬਦਲਣ ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਸੀ।
ਇੱਕ ਆਮ ਤਰੀਕਾ ਸੀ ਪਲੱਗਬੋਰਡ, ਪੈਚ ਕੇਬਲ ਅਤੇ ਸਵਿੱਚ ਪੈਨਲ ਵਰਤਣਾ। آپਰੇਟਰ ਸਾਕੇਟਾਂ ਦੇ ਵਿਚਕਾਰ ਤਾਰਾਂ ਜੋੜਦੇ, ਸਵਿੱਚ ਸੈਟ ਕਰਦੇ ਅਤੇ ਕਈ ਵਾਰੀ ਟਾਇਮਿੰਗ ਯੂਨਿਟ ਠੀਕ ਕਰਦੇ ਤਾਂ ਜੋ ਸੰਕੇਤ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਆਉਣ। “ਪ੍ਰੋਗਰਾਮ” ਕੋਈ ਫਾਈਲ ਨਹੀਂ ਸੀ ਜੋ ਤੁਸੀਂ ਲੋਡ ਕਰਦੇ — ਇਹ ਇੱਕ ਅਸਥਾਈ ਤਾਰਾਂ ਦੀ ਰੇਖਾ ਸੀ।
ਇਹ ਵਿਵਸਥਾ ਕੰਮ ਕਰਦੀ ਸੀ, ਪਰ ਇਸ ਦਾ ਛੁਪਿਆ ਖ਼ਰਚ ਸੀ: ਹਰ ਨਵੇਂ ਕੰਮ ਲਈ ਇੱਕ ਛੋਟੀ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰੋਜੈਕਟ ਕਰਨੀ ਪੈਂਦੀ ਸੀ। ਜੇ ਤੁਸੀਂ ਓਪਰੇਸ਼ਨ ਦਾ ਕ੍ਰਮ ਬਦਲਣਾ ਚਾਹੁੰਦੇ (ਜੋੜਨਾ, ਗੁਣਾ ਕਰਨਾ, ਤੁਲਨਾ, ਲੂਪ), ਤਾਂ ਸ਼ਾਇਦ ਦਹਾਂ ਜਾਂ ਸੌਂ ਤਾਰਾਂ ਨੂੰ ਮੋੜਨਾ ਪੈਂਦਾ। ਇਕ ਗਲਤ ਤਾਰ ਸੁਖੇੜੇ ਤੇਜ਼-ਨੂੰਕਸਾਨਕਾਰੀ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਸੀ, ਕਿਉਂਕਿ ਲੋਜਿਕ ਹਾਰਡਵੇਅਰ ਕਨੈਕਸ਼ਨਾਂ ਵਿੱਚ ਫੈਲੀ ਹੁੰਦੀ ਸੀ, ਨਾ ਕਿ ਪਾਠਯ ਰੂਪ ਵਿੱਚ ਲਿਖੀ ਕਦਮ-ਬਦ-ਕਦਮ ਹਦਾਇਤਾਂ ਵੱਜੋਂ।
ਰੀਕਾਨਫਿਗਰਿੰਗ ਵਿੱਚ ਘੰਟਿਆਂ ਜਾਂ ਦਿਨ ਲੱਗ ਸਕਦੇ ਸਨ, ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਮਸ਼ੀਨ ਨੂੰ ਬੜੀ ਸਾਵਧਾਨੀ ਨਾਲ ਬੰਦ ਕਰਕੇ, ਦੁਬਾਰਾ ਵਾਇਰ ਕਰਕੇ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਪੈਂਦਾ। ਇਸ ਦਾ ਨਤੀਜਾ ਸੀ ਸੀਮਤ ਲਚੀਲਾਪਣ: ਇਹ ਮਸ਼ੀਨਾਂ ਅਕਸਰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਇੱਕ ਹੀ ਕਿਸਮ ਦੀ ਗਣਨਾ ਲਈ ਸ਼ੈਡਿਊਲ ਕੀਤੀਆਂ ਹੁੰਦੀਆਂ, ਕਿਉਂਕਿ ਜਾਬ ਬਦਲਣਾ ਬਹੁਤ ਵਿਘਨਕਰ ਸੀ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਮਸ਼ੀਨ ਬਣਾਈ ਗਈ ਹੈ ਗੋਲਾਬਾਰੀ ਫਾਇਰਿੰਗ ਟੇਬਲਾਂ ਦੀ ਗਣਨਾ ਲਈ—ਲੰਬੀਆਂ, ਦੁਹਰਾਈਆਂ ਗਣਨਾਵਾਂ ਇਕ ਨਿਰਧਾਰਤ ਫਾਰਮੂਲੇ ਨਾਲ। ਜੇ ਖੋਜकर्तੇ ਫਿਰ ਹੀ ਮਸ਼ੀਨ ਨੂੰ ਹੋਰ ਸਮੱਸਿਆ (ਜਿਵੇਂ ਲੋਕਗਣਨਾ ਲਏ ਸਾਂਖਿਆਂ ਦੀ ਟੇਬੂਲੇਸ਼ਨ) ਲਈ ਵਰਤਣਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ “ਪ੍ਰੋਗਰਾਮ ਐਡਿਟ ਕਰਕੇ ਫਿਰ ਚਲਾਓ” ਦਾ ਮਾਮਲਾ ਨਹੀਂ ਸੀ। ਕਾਰਵਾਈ ਕ੍ਰਮ, ਵਿਚਕਾਰਲੀ ਸਟੋਰੇਜ ਸਟੈਪ ਅਤੇ ਸ਼ਰਤਾਂ ਹੋ ਸਕਦੀਆਂ ਸਨ ਬਿਲਕੁਲ ਵੱਖ-ਵੱਖ, ਜਿਸ ਲਈ ਪੂਰਾ ਪਲੱਗਬੋਰਡ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਅਤੇ ਫਰਮਾਨ-ਪੜਤਾਲ ਲੋੜੀਂਦੇ।
ਇਹੀ ਉਹ ਦੁਨੀਆ ਸੀ ਜਿਸਨੂੰ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਛੱਡਕੇ ਆਈ।
ਇੱਕ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਇੱਕ ਐਸੀ ਮਸ਼ੀਨ ਹੈ ਜਿੱਥੇ ਨਿਰਦੇਸ਼ (ਪ੍ਰੋਗਰਾਮ) ਉਸੇ ਵਰਕਿੰਗ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਵਰਤਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਕੰਪਿਊਟਰ “ਕਿਸੇ ਕੰਮ ਨੂੰ ਕਿਵੇਂ ਕਰਨਾ ਹੈ” ਨੂੰ “ਕਿਸ 'ਤੇ ਕੰਮ ਕਰਨਾ ਹੈ” ਨਾਲ ਵੱਖ ਨਹੀਂ ਵੇਖਦਾ—ਦੋਹਾਂ ਬਿੱਟਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਪਾਇਨੀਅਰਾਂ ਨੇ ਮੈਮੋਰੀ ਦੀ ਗੱਲ ਕੀਤੀ, ਉਹ ਉਸ ਤੇਜ਼, ਸਿੱਧੀ ਤਰ੍ਹਾਂ ਵਰਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਅੰਦਰੂਨੀ ਸਟੋਰੇਜ ਨੂੰ ਮਨ ਵਿੱਚ ਰੱਖਦੇ ਸਨ—ਜਿਸਨੂੰ ਅਸੀਂ ਹੁਣ ਆਮ ਤੌਰ 'ਤੇ RAM ਨਾਲ ਜੋੜਦੇ ਹਾਂ। ਇਹ ਓਸ ਥਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰੋਸੈਸਰ ਚਲਾਉਂਦੇ ਸਮੇਂ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦਾ ਹੈ।
ਇਹ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਸਟੋਰੇਜ (ਜਿਵੇਂ ਹਾਰਡ ਡਰਾਈਵ ਜਾਂ SSD) ਤੋਂ ਵੱਖ ਹੈ। ਡਰਾਈਵ ਬਿਜਲੀ ਵਿੱਛੋਂ ਬੰਦ ਹੋਣ 'ਤੇ ਫਾਈਲਾਂ ਰੱਖਣ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਇਹ ਤੁਰੰਤ ਸਪੈਚਪੈੱਡ ਨਹੀਂ ਹੈ ਜਿੱਥੋਂ ਪ੍ਰੋਸੈਸਰ ਅਗਲਾ ਨਿਰਦੇਸ਼ ਲੈਦਾ ਅਤੇ ਵਿਚਕਾਰਲੇ ਨਤੀਜੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
ਜਦ ਨਿਰਦੇਸ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਤਾਸੀਰਦਾਰ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਬਦਲਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਨਵਾਂ ਪ੍ਰੋਗਰਾਮ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਕਰਦੇ ਹੋ ਅਤੇ ਚਲਾਉਂਦੇ ਹੋ, ਬਿਨਾਂ ਦੁਬਾਰਾ ਬਣਾਏ, ਵਾਇਰ ਕਰਕੇ ਜਾਂ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਕਨਫਿਗਰ ਕਰਕੇ। ਉਹੀ ਜਨਰਲ-ਪਪਰਪਸ ਮਸ਼ੀਨ ਸਵੇਰੇ ਪੇਰੋਲ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਦੁਪਹਿਰ ਬੈਲਿਸਟਿਕਸ ਗਣਨਾ—ਕਿਉਂਕਿ ਕੰਮ ਦਾ “ਕਿਵੇਂ” ਸਿਰਫ਼ ਬਿੱਟਾਂ ਦਾ ਇੱਕ ਹੋਰ ਸੈਟ ਹੈ ਜਿਹਨੂੰ ਤੁਸੀਂ ਬਦਲ ਸਕਦੇ ਹੋ।
ਇੱਕ ਰਸੋਈ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿੱਥੇ ਰੈਸੀਪੀ ਅਤੇ ਸਮੱਗਰੀ ਇੱਕੋ ਸ਼ੈਲਫ਼ ਵਿੱਚ ਇਕੱਠੇ ਰੱਖੇ ਹਨ। ਰਸੋਈਆ (ਪ੍ਰੋਸੈਸਰ) بار-بار ਸ਼ੈਲਫ਼ (ਮੈਮੋਰੀ) ਤੇ ਜਾਂਦਾ ਹੈ ਅਗਲਾ ਰੈਸੀਪੀ ਕਦਮ (ਨਿਰਦੇਸ਼) ਪੜ੍ਹਨ ਲਈ ਅਤੇ ਸਮੱਗਰੀ (ਡਾਟਾ) ਲੈਣ ਜਾਂ ਅਪਡੇਟ ਕਰਨ ਲਈ।
ਹੁਣ ਹੋਰ ਖਾਣਾ ਬਣਾਉਣਾ ਹੈ? ਤੁਸੀਂ ਰਸੋਈ ਦੀ ਨਿਰਮਾਣ-ਸੰਰਚਨਾ ਨਹੀਂ ਬਦਲਦੇ। ਕੇਵਲ ਨਵੀਂ ਰੈਸੀਪੀ ਲਗਾਉਂਦੇ ਹੋ—ਉਹੀ ਕਾਊਂਟਰ, ਓਵਨ ਅਤੇ ਸਾਧਨ ਵਰਤਦੇ ਹੋ।
John von Neumann ਨੇ “ਕੰਪਿਊਟਰ ਊਂਝ ਇਜਾਦ ਨਹੀਂ ਕੀਤਾ”, ਅਤੇ ਨਾ ਹੀ ਇਕੱਲੇ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਵਿਚਾਰ ਨੂੰ ਪੈਦਾ ਕੀਤਾ। ਉਹ ਜੋ ਕਰਦੇ ਸਨ—ਉਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ—ਇੱਕ ਉਮੀਦਵਾਰ ਵਿਚਾਰ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਰੱਖ ਕੇ ਐਸਾ ਡਿਜ਼ਾਈਨ ਦਿਤਾ ਜੋ ਹੋਰ ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਲੈਬਾਂ ਅਸਾਨੀ ਨਾਲ ਬਣਾ ਸਕਣ।
Von Neumann ਦੂਜੇ ਯੁੱਧ ਅਤੇ ਪੋਸਟ-ਵਾਰ ਕੰਪਿਊਟਿੰਗ ਪ੍ਰਾਜੈਕਟਾਂ ਵਿੱਚ ਗਹਿਰਾਈ ਨਾਲ ਸ਼ਾਮਿਲ ਸੀ, ਟੀਮਾਂ ਦੀ ਸਲਾਹ-ਮਸ਼ਵਰਾ ਕੀਤੀ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਈਨਾਂ ਦੀ ਲੌਜਿਕਲ ਸੰਰਚਨਾ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ। ਉਹ ਜਟਿਲ ਤਕਨੀਕੀ ਚੋਣਾਂ ਨੂੰ ਸਪਸ਼ਟ, ਸੋਚ-ਵਿਚਾਰ ਨਾਲ ਸਮਝਾਉਣ ਦੀ ਖ਼ਾਸੀਅਤ ਰੱਖਦੇ ਸਨ, ਅਤੇ ਇਸਦਾ ਮਹੱਤਵ ਇਸ ਲਈ ਸੀ ਕਿਉਂਕਿ ਇਲੈਕਟ੍ਰਾਨਿਕ ਕੰਪਿਊਟਿੰਗ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਰਹੀ ਸੀ ਅਤੇ ਕਈ ਸਮੂਹ ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰ ਰਹੇ ਸਨ।
ਅਤਿ-ਜਰੂਰੀ ਗੱਲ, ਉਹਨਾਂ ਨੇ ਅਜਿਹੀਆਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਵਰਣਨਾਵਾਂ ਲਿਖੀਆਂ ਅਤੇ ਫੈਲਾਈਆਂ ਜਿੱਥੇ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿ ਇੱਕ ਕੰਪਿਊਟਰ ਕਿਵੇਂ ਪ੍ਰੋਗਰਾਮ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਉਹੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ ਜੋ ਡਾਟਾ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਸਪਸ਼ਟ ਫਰੇਮਿੰਗ ਹੋਰ ਲੋਕਾਂ ਲਈ ਚਰਚਾ, ਸਿਖਲਾਈ ਅਤੇ ਨਕਲ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਸੀ।
ਨਾਮ ਅਕਸਰ ਉਸ ਵਿਅਕਤੀ ਨਾਲ ਜੁੜਦੇ ਹਨ ਜਿਸ ਦੀ ਵਰਣਨਾ ਸੰਦਰਭ-ਬਿੰਦੂ ਬਣ ਜਾਂਦੀ ਹੈ, ਨ ਕਿ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੇ ਨਾਲ। Von Neumann ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਈਆਂ, ਕਾਪੀ ਕੀਤੀਆਂ ਅਤੇ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ—ਇਸ ਲਈ ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹਨ ਵਾਲੇ ਨੇ ਰੁਝਾਨੀ ਤੌਰ 'ਤੇ “ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ” ਵਿਵਸਥਾ ਨੂੰ ਉਸ ਨਾਲ ਜੋੜ ਦਿੱਤਾ।
ਇਹ ਲੇਬਲ ਇਤਿਹਾਸ ਨੂੰ ਵੀ ਸਧਾਰਨ ਕਰ ਦਿੰਦਾ ਹੈ: “von Neumann architecture” ਕਹਿਣਾ ਆਸਾਨ ਹੈ ਬਣਾਮ ਹਰ ਯੋਗਦਾਨ ਦੀ ਸੂਚੀ ਕਰਨ ਦੇ। ਪਰ ਇਹ ਛੋਟਾ-ਸਾਰ ਇਤਿਹਾਸ ਹਕੀਕਤ ਨੂੰ ਥੋੜ੍ਹਾ ਧੁੰਦਲਾ ਕਰ ਸਕਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਇਲੈਕਟ੍ਰਾਨਿਕ ਕੰਪਿਊਟਿੰਗ ਗਣਿਤਗਿਆਨੀਆਂ, ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਦੀ ਸਾਂਝੀ ਕੋਸ਼ਿਸ਼ ਸੀ। ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਧਾਰਨਾ ਵਿਚਾਰ-ਚਰਚਾ, ਡਰਾਫਟ, ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਟੀਮਾਂ ਵੱਚ ਸੁਧਾਰਾਂ ਰਾਹੀਂ ਪੱਕੀ ਹੋਈ। Von Neumann ਦੀ ਲੰਬੀ ਅਵਧੀ ਦੀ ਭੂਮਿਕਾ ਇਹ ਸੀ ਕਿ ਉਹਨਾਂ ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਖੂਬ ਸਾਰਥਕ ਬਣਾ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਅਪਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕੀਤੀ—ਨਾ ਕਿ ਉਹ ਇਸ ਨੂੰ ਇਕੱਲੇ ਹੀ ਬਣਾਇਆ।
EDVAC (Electronic Discrete Variable Automatic Computer) ਪਹਿਲੇ ਜੰਗ-ਉੱਤਰ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ ਜੋ "ਇੱਕ-ਆਫ" ਮਸ਼ੀਨਾਂ ਤੋਂ ਪਰੇ ਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ। ਹਾਰਡਵੇਅਰ ਕੰਮ ਦੇ ਨਾਲ-ਨਾਲ ਇਹ ਫੈਸਲਾ ਵੀ ਮਹੱਤਵਪੂਰਕ ਸੀ ਕਿ ਡਿਜ਼ਾਈਨ ਵਿਚਾਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਲਿਖਿਆ ਜਾਵੇ। ਉੱਥੇ ਸਮਾਂ, ਕੰਪਿਊਟਰ ਬਣਾਉਣਾ ਅਜੇ ਵੀ ਪ੍ਰਯੋਗਾਤਮਕ ਇੰਜੀਨੀਅਰਿੰਗ ਸੀ—ਜਾਣਕਾਰੀ ਲੈਬ ਨੋਟਬੁੱਕਾਂ, ਮੀਟਿੰਗਾਂ ਅਤੇ ਕੁਝ ਵਿਸ਼ੇਸ਼ਜਾਂ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਰਹਿੰਦੀ ਸੀ। ਇੱਕ ਰਿਪੋਰਟ ਉਹ ਤਰ੍ਹਾਂ ਦੇ ਵਿਖਰੇ ਹੋਏ ਅਨੁਭਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ ਹੋਰ ਟੀਮਾਂ ਲਈ ਚਰਚਾ, ਟਿੱਪਣੀ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ ਯੋਗ ਬਣਾਉਂਦੀ ਸੀ।
First Draft of a Report on the EDVAC (ਅਕਸਰ “EDVAC report” ਆਖਿਆ ਜਾਂਦਾ) ਨੇ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਵਿਚਾਰ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਰੱਖਿਆ: ਇੱਕ ਕੰਪਿਊਟਰ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਉਹੀ ਕਿਸਮ ਦੀ ਅੰਦਰੂਨੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਡਾਟਾ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਉਹ ਮੈਮੋਰੀ ਸਿਰਫ਼ ਨੰਬਰ ਰੱਖਣ ਲਈ ਨਹੀਂ ਹੈ ਜਦ ਗਣਨਾ ਚੱਲ ਰਹੀ ਹੁੰਦੀ ਹੈ—ਇਹ ਕਦਮਾਂ ਨੂੰ ਵੀ ਰੱਖਦੀ ਹੈ ਜੋ ਮਸ਼ੀਨ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਅਗਲੇ ਕੀ ਕਰਨੇ ਹਨ।
ਇਹ ਫਰੇਮਿੰਗ ਕੰਪਿਊਟਰ ਨੂੰ ਇੱਕ ਸਥਿਰ-ਮਕਸਦ ਯੰਤਰ ਵਜੋਂ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਾਉਂਦੀ, ਬਲਕਿ ਇੱਕ ਆਮ-ਉਦੇਸ਼ ਮਸ਼ੀਨ ਵਜੋਂ ਜੋ ਮੈਮੋਰੀ ਵਿੱਚ ਮੌਜੂਦ ਚੀਜ਼ਾਂ ਬਦਲ ਕੇ “ਦੁਬਾਰਾ ਟਾਸਕ” ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਕੰਮ ਤੋਂ ਦੂਜੇ ਕੰਮ ਤੇ ਸਵਿੱਚ ਕਰਨ ਲਈ ਵਾਇਰਿੰਗ ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਵੱਖਰੀ ਲੜੀ ਲੋਡ ਕਰਦੇ ਹੋ।
ਸਿੱਧ ਧਾਰਨਾ ਤੋਂ ਅਲਾਵਾ, ਰਿਪੋਰਟ ਨੇ ਲੋਕਾਂ ਲਈ ਉਹ ਭਾਸ਼ਾ ਵੀ ਸਥਾਪਿਤ ਕੀਤੀ ਜਿਸ ਨਾਲ ਉਹ ਕੰਪਿਊਟਰਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਸਕਦੇ ਸਨ: ਮੈਮੋਰੀ, ਕੰਟਰੋਲ, ਅੰਕਗਣਿਤ ਅਤੇ ਇਨਪੁਟ/ਆਉਟਪੁਟ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਾਂਝਾ ਮਾਨਸਿਕ ਮਾਡਲ ਅਤੇ ਵਿਆਖਿਆ ਹੋਣ ਨਾਲ ਨਾ ਸਿਰਫ EDVAC ਨੂੰ ਸਮਝਾਉਣ ਵਿੱਚ ਮਦਦ ਮਿਲੀ—ਇਸ ਨੇ ਬੜੇ ਖੇਤਰ ਨੂੰ ਇਹ ਸਿਖਾਇਆ ਕਿ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਕਿਵੇਂ ਬਣਾਉਣ, ਤੁਲਨਾ ਕਰਨ ਅਤੇ ਸੁਧਾਰਨਗੇ।
ਇਹ ਪੁੱਛਣਾ ਆਸਾਨ ਹੈ “ਕਿਸने ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਦਾ ਆਵਿਸਕਾਰ ਕੀਤਾ?” ਤੇ ਇੱਕ ਹੀ ਨਾਮ ਦੀ ਉਮੀਦ ਰੱਖਣਾ। ਪਰ ਵਿਗਿਆਨ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਚਲਦੇ। ਵਿਚਾਰ ਅਕਸਰ ਸਮਕਾਲੀ ਤੌਰ ਤੇ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ, ਗੱਲ-ਬਾਤ ਦੁਆਰਾ ਸੁਧਰੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੈਰ ਸਵੀਕਾਰਯੋਗ ਹੋਂਦ ਵਿੱਚ ਤਦ ਹੀ ਆਉਂਦੇ ਹਨ ਜਦ ਉਨ੍ਹਾਂ ਨੂੰ ਕਾਰਯਾਨਕ ਹਾਰਡਵੇਅਰ ਵਿੱਚ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ।
John von Neumann ਨਾਲ ਸਟੋਰਡ-ਪ੍ਰোগ੍ਰਾਮ ਧਾਰਨਾ ਭੁੱਤ ਮਜ਼ਬੂਤੀ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ, ਪਰ ਸ਼ੁਰੂਆਤੀ ਕੰਮ ਵਿੱਚ ਕਈ ਲੋਕ ਅਤੇ ਸਮੂਹ ਸ਼ਾਮِل ਸਨ:
ਇੱਕ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਇੱਕ ਇਕੱਲਾ ਇNOVੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਹ (1) ਉਹ ਧਾਰਨਾ ਕਿ ਨਿਰਦੇਸ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਡਾਟਾ ਵਾਂਗ ਹੀ ਰਹਿ ਸਕਦੇ ਹਨ, (2) ਭਰੋਸੇਯੋਗ ਮੈਮੋਰੀ ਅਤੇ ਕੰਟਰੋਲ ਯੂਨਿਟ ਬਣਾਉਣ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ, ਅਤੇ (3) ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਭਿਆਸਾਂ ਜੋ ਡਿਜ਼ਾਈਨ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ—ਇਨ੍ਹਾਂ ਦੀ ਜੋੜ ਹੈ। ਵੱਖ-ਵੱਖ ਲੋਕ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾ ਰਹੇ ਸਨ।
ਇੱਕ ਹੋਰ ਕਾਰਨ ਕਿ ਯੋਗਦਾਨ ਵੰਡਿਆ ਗਿਆ ਹੈ: ਇੱਕ ਵਿਚਾਰ ਪੇਸ਼ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਉਹ ਮਸ਼ੀਨ ਬਣਾਉਣਾ ਜਿੰਨੂੰ ਰੋਜ਼ਾਨਾ ਚਲਾਇਆ ਜਾ ਸਕੇ, ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਰਿਪੋਰਟਾਂ ਅਤੇ ਗੱਲ-ਬਾਤ ਨੇ ਧਾਰਨਾ ਨੂੰ ਸਪਸ਼ਟ ਕੀਤਾ; ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਨੇ ਇਹ ਸਾਬਤ ਕੀਤਾ ਕਿ ਇਹ ਸੰਭਵ ਹੈ। ਇੱਕ ਧਿਆਨਪੂਰਣ ਇਤਿਹਾਸ ਦੋਹਾਂ ਕਿਸਮਾਂ ਦੇ ਯੋਗਦਾਨਾਂ ਦਾ ਸਨਮਾਨ ਕਰਦਾ ਹੈ—ਬਿਨਾਂ ਕਿਸੇ ਸਧਾਰਨ “ਪਹਿਲਾ ਆਵਿਸਕਾਰਕ” ਨਤੀਜੇ 'ਤੇ ਆਉਣ ਦੇ।
ਜਦ ਲੋਕ “von Neumann architecture” ਕਹਿੰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਧਾਰਣ, ਸਕੂਲ-ਵਿੱਚ ਸਿਖਾਈ ਜਾਂਦੀ ਮਾਡਲ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਕਿ ਇੱਕ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਕਿਵੇਂ ਮਨੋਰਥਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਕੋਈ ਬ੍ਰੈਂਡ ਜਾਂ ਇੱਕ ਹੀ ਇਤਿਹਾਸਕ ਮਸ਼ੀਨ ਨਹੀਂ—ਇਹ ਇੱਕ ਆਸਾਨ ਸੂਚਕ ਹੈ ਜੋ ਕਈ ਕੰਪਿਊਟਰਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਰੂਪਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ।
ਸੰਕਲਪਿਕ ਪੱਧਰ 'ਤੇ ਇਸ ਤਸਵੀਰ ਵਾਂਗ:
ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ CPU ਕੋਲ “ਪ੍ਰੋਗਰਾਮ” ਅਤੇ “ਨੰਬਰ” ਲਈ ਵੱਖਰਾ ਭੌਤਿਕ ਸਥਾਨ ਨਹੀਂ ਹੈ। ਇਹ ਸਾਰਾ ਕੁਝ ਮੈਮੋਰੀ ਤੋਂ ਖਿੱਚਦਾ ਹੈ।
CPU ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇੱਕ ਲੂਪ ਦੁਹਰਾਉਂ ਕੇ ਚਲਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਅਕਸਰ fetch–decode–execute ਕਿਹਾ ਜਾਂਦਾ ਹੈ:
ਇਹ ਵਰਣਨ ਸਧਾਰਣ ਹੈ, ਪਰ ਮੁੱਖ ਗੱਲ ਫੜਦਾ ਹੈ: ਪ੍ਰੋਗਰਾਮ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਲੜੀ ਮੈਮੋਰੀ ਵਿੱਚ ਹੈ, ਅਤੇ CPU ਉਨ੍ਹਾਂ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਅਗੇ ਵਧਦਾ ਹੈ।
ਨਿਰਦੇਸ਼ਾਂ ਅਤੇ ਡਾਟਾ ਨੂੰ ਇਕੱਠੇ ਰੱਖਣ ਨਾਲ ਕੰਪਿਊਟਰ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਜਨਰਲ-ਪਪਰਪਸ ਬਣ ਜਾਂਦਾ ਹੈ:
ਇਸ ਲਈ “von Neumann architecture” ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਇੱਕ ਛੋਟਾ-ਸਰਲੀਕ੍ਰਿਤ ਨਾਮ ਜੋ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਮਾਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ—CPU, ਇਕ ਸਾਂਝੀ ਮੈਮੋਰੀ ਜਿਸ ਵਿੱਚ ਨਿਰਦੇਸ਼ ਅਤੇ ਡਾਟਾ ਹਨ, ਅਤੇ I/O—ਇਹ ਵਿਚਾਰ von Neumann ਦੀ ਸਪਸ਼ਟ ਵਿਆਖਿਆ ਨਾਲ ਜੁੜਿਆ ਹੈ, ਹਾਲਾਂਕਿ ਸ਼ੁਰੂਆਤੀ ਕਹਾਣੀ ਵਿੱਚ ਬਹੁਤੇ ਯੋਗਦਾਨੀ ਸਨ।
ਲੋਕ ਅਕਸਰ “von Neumann” ਅਤੇ “Harvard” ਨੂੰ ਮੁਕਾਬਲੀ ਫਿਲਾਸਫੀਆਂ ਵਾਂਗ ਵੇਖਦੇ ਹਨ। ਦਰਅਸਲ, ਇਹ ਦੋ ਪ੍ਰਯੋਗਕ ਤਰੀਕੇ ਹਨ ਜੋ ਪ੍ਰੋਗਰਾਮ ਨਿਰਦੇਸ਼ਾਂ ਅਤੇ ਡਾਟਾ ਦੀ ਵਿਵਸਥਾ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਕੰਪਿਊਟਰ ਜਿੰਨੀ ਜ਼ਰੂਰਤ ਹੈ, ਉਹ ਲੈ ਸਕੇ।
von Neumann-ਸਟਾਈਲ ਡਿਜ਼ਾਇਨ ਵਿੱਚ, ਨਿਰਦੇਸ਼ ਅਤੇ ਡਾਟਾ ਇਕੋ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ CPU ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਉਹੀ ਮੁੱਖ ਰਸਤਾ ਵਰਤਦੇ ਹਨ।
ਇਹ ਸੰਕਲਪਿਕ ਤੌਰ 'ਤੇ ਸਾਦਾ ਹੈ: ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਮੈਮੋਰੀ ਵਿੱਚ ਬਾਈਟਸ ਵਾਂਗ ਹੀ ਹੈ, ਨੰਬਰਾਂ, ਟੈਕਸਟ ਅਤੇ ਚਿੱਤਰਾਂ ਦੇ ਨਾਲ। ਇਹ ਜਨਰਲ-ਪਪਰਪਸ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦਾ—ਸਾਫਟਵੇਅਰ ਲੋਡ, ਬਦਲ ਅਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਟਰੇਡ-ਓਫ਼: ਜਦ ਨਿਰਦੇਸ਼ ਅਤੇ ਡਾਟਾ ਇੱਕੋ “ਸੜਕ” ਸਾਂਝੇ ਕਰਦੇ ਹਨ, ਉਹ ਬੈਂਡਵਿਡਥ ਲਈ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦੇ ਹਨ। (ਇਸਨੂੰ ਅਕਸਰ “ਬੋਟਲਨੇਕ” ਕਿਹਾ ਜਾਂਦਾ ਹੈ।)
Harvard-ਸਟਾਈਲ ਵਿੱਚ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਸਟੋਰੇਜ ਡਾਟਾ ਤੋਂ ਵੱਖ ਰੱਖੀ ਜਾਂਦੀ ਹੈ, ਅਕਸਰ ਦੋ ਵੱਖਰੇ ਰਸਤੇ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਰਾਹੀਂ ਇਹ CPU ਤੱਕ ਜਾਂਦੀਆਂ ਹਨ।
ਇਹ ਵਖਰੇਪਣ ਅਗਲੇ ਨਿਰਦੇਸ਼ ਨੂੰ ਖਿੱਚਣ ਵੇਲੇ ਇਕੱਥੇ ਡਾਟਾ ਨੂੰ ਪੜ੍ਹਨ/ਲਿਖਣ ਵਿੱਚ ਆਸਾਨੀ ਕਰ ਸਕਦਾ ਹੈ—ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ, ਅਨੁਮਾਨਕ ਰੂਪ ਵਾਲੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਲਾਭਦਾਇਕ। ਉਦਾਹਰਨ ਵਜੋਂ ਕਈ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਜਿੱਥੇ ਕੋਡ flash ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਵੇਰੀਏਬਲ RAM ਵਿੱਚ।
ਆਧੁਨਿਕ CPU ਅਕਸਰ ਸੌਫਟਵੇਅਰ ਨੂੰ ਇੱਕ von Neumann ਤਜਰਬਾ ਦਿੰਦੇ ਹਨ (ਇੱਕ ਐਡਰੇਸ ਸਪੇਸ, ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਮਾਡਲ), ਪਰ ਅੰਦਰੂਨੀ ਤੌਰ Harvard-ਨੁਮਾ ਵਿਚਾਰ ਵਰਤਦੇ ਹਨ। ਇੱਕ ਆਮ ਉਦਾਹਰਨ ਹੈ ਇਨਸਟਰਕਸ਼ਨ ਕੈਸ਼ ਅਤੇ ਡਾਟਾ ਕੈਸ਼ ਦੀ ਵੱਖਰੀ ਬਣਤਰ। ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇਹ ਇੱਕੋ ਮੈਮੋਰੀ ਵਾਂਗ ਲੱਗਦਾ ਹੈ, ਪਰ ਹਾਰਡਵੇਅਰ ਕੋਡ ਅਤੇ ਡਾਟਾ ਨੂੰ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।
ਯਾਦ ਰੱਖੋ: ਕੋਈ ਸਰਵੋਤਮ ਜਿੱਤ ਵਾਲਾ ਨਹੀਂ। Von Neumann ਸਾਦਗੀ ਅਤੇ ਲਚੀਲਾਪਣ ਉੱਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ; Harvard ਵਿਭਾਜਨ ਅਤੇ ਪਹੁੰਚ ਤੇ। ਬਹੁਤ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ ਦੋਹਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਯੋਗਤਾ, ਲਾਗਤ, ਪਾਵਰ ਅਤੇ ਗਤੀ ਦਾ ਸੰਤੁਲਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਇੱਕ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਕੰਪਿਊਟਰ ਸਿਰਫ਼ ਗਣਨਾਵਾਂ ਚਲਾਉਂਦਾ ਨਹੀਂ—ਇਹ ਮੈਮੋਰੀ ਤੋਂ ਨਿਰਦੇਸ਼ ਲੋਡ ਕਰ ਸਕਦਾ, ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾ ਸਕਦਾ, ਅਤੇ ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਵੱਖਰੇ ਨਿਰਦੇਸ਼ ਲੋਡ ਕਰ ਸਕਦਾ। ਇਸ ਬਦਲਾਅ ਨੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਦੁਬਾਰਾ-ਵਰਤਣਯੋਗ ਅਤੇ ਸਾਂਝਾ ਯੋਗ ਬਣਾਇਆ: ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਵਾਰੀ ਲਿਖਿਆ ਜਾ ਸਕਦਾ, ਸੇਵ ਹੋ ਸਕਦਾ, ਕਾਪੀ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਅਤੇ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਬਿਨਾਂ ਹਾਰਡਵੇਅਰ ਛੂਹੇ।
ਜਦ ਪ੍ਰੋਗਰਾਮ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਉਹੀ ਭੌਤਿਕ ਕੰਪਿਊਟਰ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਕੰਮ ਕਰ ਸਕਦਾ ਕੇਵਲ ਨਿਰਦੇਸ਼ ਬਦਲ ਕੇ। ਇਹੀ ਹੈ ਜੋ “ਜਨਰਲ-ਪਪਰਪਸ” ਦਾ ਅਸਲ ਮਤਲਬ ਹੈ: ਇੱਕ ਮਸ਼ੀਨ, ਬਹੁਤ ਪ੍ਰੋਗਰਾਮ। ਕੰਪਿਊਟਰ ਹੁਣ ਇੱਕ ਹੀ ਵਰਕਫਲੋ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਰਹਿੰਦਾ; ਇਹ ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਆਧੁਨਿਕ ਉਦਾਹਰਨ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਦੀ ਹੈ ਜੋ ਈਮੇਲ, ਗੇਮ ਅਤੇ ਸਪਰੇਡਸ਼ੀਟ ਚਲਾਉਂਦਾ ਹੈ—ਹਰ ਏਪ ਵੱਖਰਾ ਨਿਰਦੇਸ਼ ਸੈੱਟ ਲੋਡ ਕਰਦਾ ਹੈ ਪਰ ਹਾਰਡਵੇਅਰ ਇੱਕੋ ਹੀ ਰਹਿੰਦਾ ਹੈ।
ਜਦ ਨਿਰਦੇਸ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਡਾਟਾ ਵਾਂਗ ਵੇਖੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਐਸੇ ਸਾਧਨਾਂ ਦੀ ਬਣਾਵਟ ਵਰਤੋਂਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸਾਫਟਵੇਅਰ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:
ਇਹ ਟੂਲ ਇਹ ਮੰਨ ਕੇ ਬਣੇ ਕਿ ਪ੍ਰੋਗਰਾਮ ਸਟੋਰ ਹੋ ਸਕਦੇ, ਹਿਲ ਸਕਦੇ ਅਤੇ ਸੋਧੇ ਜਾ ਸਕਦੇ ਹਨ—ਇਹੀ ਗੱਲ ਸਾਫਟਵੇਅਰ ਨੂੰ ਇੱਕ ਪਰਿਸ਼ਰ ਬਨਾਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ-ਵਾਰਗੀ ਚੀਜ਼ ਜੋ ਇਕ ਖਾਸ ਵਾਇਰਿੰਗ ਨਾਲ ਜੁੜੀ ਹੋਵੇ।
ਲੰਬੇ ਵੇਲੇ ਨੂੰ ਵੇਖਣ ਲਈ: ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮਾਂ ਨੇ ਕੰਪਾਈਲਰਾਂ ਅਤੇ OS-ਜ਼ ਨੂੰ ਯੋਗ ਬਣਾਇਆ, ਜਿਸ ਨਾਲ ਡਿਵੈਲਪਰ ਟੂਲਿੰਗ ਹੋਈ—ਅੱਜ ਸਾਨੂੰ ਇੱਕ ਹੋਰ ਪਰਤ ਦਿੱਸ ਰਹੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਵਿੱਚ ਇਕ ਐਪ ਦਾ ਵਰਣਨ ਕਰਕੇ ਟੂਲਜ਼ ਵੱਲੋਂ ਕੰਮਯੋਗ ਕੋਡ ਤਿਆਰ ਕਰਵਾ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਬੈਕਏਂਡ ਜਾਂ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਂਦੇ ਹੋ; ਇਸੀਂ LLMs ਅਤੇ ਏਜੇਂਟ-ਅਧਾਰਤ ਵਰਕਫਲੋ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ ਭਾਵਨਾ ਤੋਂ ਚਲਾਉਣਯੋਗ ਕੋਡ ਤੱਕ ਰਸਤਾ ਤੇਜ਼ ਕਰਦਾ ਹੈ।
ਨਤੀਜਾ ਇਕੋ ਆਦਰਸ਼ ਚੱਕਰ ਹੈ: ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮਾਂ ਨੇ ਬਿਹਤਰ ਟੂਲ ਬਣਾਉਣਗੇ ਯੋਗ ਕੀਤਾ, ਅਤੇ ਬਿਹਤਰ ਟੂਲ ਨੇ ਹੋਰ ਮਹਾਨ ਪ੍ਰੋਗਰਾਮ ਬਣਾਉਣ ਯੋਗ ਕੀਤਾ—ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਲਚੀਲਾ, ਜਨਰਲ-ਪਪਰਪਸ ਮਸ਼ੀਨ ਬਣਾ ਦਿੱਤਾ।
ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਵਿਚਾਰ ਨੇ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਲਚੀਲਾ ਬਣਾਇਆ, ਪਰ ਇਸ ਨਾਲ ਇਕ ਪ੍ਰਯੋਗਾਤਮਕ ਸੀਮਾ ਵੀ ਸਪਸ਼ਟ ਹੋਈ ਜਿਸ ਬਾਰੇ ਇੰਜੀਨੀਅਰ ਅਜੇ ਵੀ ਗੱਲ ਕਰਦੇ ਹਨ: “von Neumann ਬੋਟਲਨੇਕ।” ਰੋਜ਼ਮਰਾ ਭਾਸ਼ਾ ਵਿੱਚ, ਇਹ CPU (ਕੰਮ ਕਰਨ ਵਾਲਾ) ਅਤੇ ਮੈਮੋਰੀ (ਖਚਾ) ਦੇ ਵਿਚਕਾਰ ਸੜਕ 'ਤੇ ਟ੍ਰੈਫਿਕ ਜੈਮ ਵਰਗਾ ਹੈ।
ਆਮ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਡਿਜ਼ਾਈਨ ਵਿੱਚ, ਨਿਰਦੇਸ਼ ਅਤੇ ਡਾਟਾ ਦੋਹਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। CPU ਇੱਕ ਨਿਰਦੇਸ਼ ਖਿੱਚਦਾ, ਫਿਰ ਉਸ ਡਾਟੇ ਨੂੰ ਖਿੱਚਦਾ ਜੋ ਲੋੜੀਂਦਾ, ਫਿਰ ਨਤੀਜੇ ਵਾਪਸ ਲਿਖਦਾ—ਅਕਸਰ ਉਹੀ ਕਨੈਕਸ਼ਨ ਵਰਤ ਕੇ। ਜੇ ਉਹ ਕਨੈਕਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਜਾਣਕਾਰੀ ਨਹੀਂ ਲੈ ਸਕਦਾ, ਤਾਂ CPU ਉਡੀਕ ਕਰਦਾ ਰਹਿੰਦਾ ਭਾਵੇਂ ਕਿ ਇਹ ਹੋਰ ਗਣਨਾ ਕਰ ਸਕਦਾ ਹੋਵੇ।
ਦੋ ਨਾਲ-ਜੁੜੇ ਤੱਤ ਇਸ ਬੋਟਲਨੇਕ ਨੂੰ ਪਰਿਭਾਸ਼ਤ ਕਰਦੇ ਹਨ:
ਇੱਕ CPU ਅਰਬਾਂ ਗਣਨਾਵਾਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਮੈਮੋਰੀ ਨਿਰੰਤਰ ਨਿਰਦੇਸ਼ਾਂ ਅਤੇ ਡਾਟਾ ਦਾ ਸਥਿਰ ਪ੍ਰਵਾਹ ਦਿੰਦੀ ਨਹੀਂ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਉਸ ਸਭ ਤੋਂ ਧੀਮੀ ਕੜੀ ਦੁਆਰਾ ਸੀਮਿਤ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਹ ਇੱਕ ਵਿਆਪਕ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਚਾਰ ਹੈ, ਅਤੇ ਆਧੁਨਿਕ ਕੰਪਿਊਟਰ ਇਸਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣ ਲਈ ਕਈ ਤਕਨੀਕਾਂ ਵਰਤਦੇ ਹਨ:
ਇਹ ਤਰੀਕੇ ਮੂਲ “ਸੜਕ” ਨੂੰ ਮਿਟਾਉਂਦੇ ਨਹੀਂ, ਪਰ ਇਸਨੂੰ ਘੱਟ-ਜਾਮੀ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ—ਤਾਂ ਜੋ CPU ਜ਼ਿਆਦਾ ਸਮਾਂ ਕੰਮ ਕਰੇ ਅਤੇ ਘੱਟ ਸਮਾਂ ਉਡੀਕ ਕਰੇ।
ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਧਾਰਨਾ ਕੋਈ ਪ੍ਰਦਰਸ਼ਨੀ ਟੁਕੜਾ ਨਹੀਂ—ਇਹ ਹਰ-ਰੋਜ਼ ਦੇ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਲਚੀਲਾ ਰੱਖਦਾ ਹੈ। ਤੁਹਾਡੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਨਵਾਂ ਕੰਮ ਕਰਨ ਲਈ “ਰੀਵਾਇਰ” ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ; ਉਹ ਸਿਰਫ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਨਿਰਦੇਸ਼ ਲੋਡ ਕਰਕੇ ਚਲਾਉਂਦੇ ਹਨ।
ਫੋਨ ਤੇ ਇੱਕ ਐਪ ਆਈਕਨ 'ਤੇ ਟੈਪ ਕਰਨ 'ਤੇ ਓਐਸ ਉਸ ਐਪ ਦਾ ਕੋਡ (ਨਿਰਦੇਸ਼) ਸਟੋਰੇਜ ਤੋਂ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਕਰਦਾ ਹੈ, ਫਿਰ CPU ਇਸਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਲੈਪਟਾਪ 'ਤੇ ਵੀ ਜਦ ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਖੋਲ੍ਹਦੇ ਹੋ, ਦਸਤਾਵੇਜ਼ ਸੰਪਾਦਨ ਕਰਦੇ ਹੋ ਜਾਂ ਗੇਮ ਚਲਾਉਂਦੇ ਹੋ, ਉਹੀ ਚੀਜ਼ ਹੁੰਦੀ ਹੈ। ਸਰਵਰਾਂ ਵਿੱਚ, ਇਹ ਹੋਰ ਵੀ ਜ਼ਿਆਦਾ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ: ਮਸ਼ੀਨ ਹਜ਼ਾਰਾਂ ਬਦਲਦੇ ਹੋਏ ਵਰਕਲੋਡ ਚਲਾ ਸਕਦੀ ਹੈ—ਵਿਨਾਂ ਹਾਰਡਵੇਅਰ ਬਦਲੇ।
ਜੋ ਵੀ ਅਸੀਂ “ਹਾਰਡਵੇਅਰ-ਜਿਹਾ” ਸਮਝਦੇ ਹਾਂ, ਅਕਸਰ ਸੋਫਟਵੇਅਰ-ਜਣਿਤ ਹੁੰਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਰਾਊਟਿੰਗ, ਵੀਡੀਓ ਡੀਕੋਡਿੰਗ, ਫੋਟੋ ਸੁਧਾਰ ਅਤੇ ਪਾਵਰ ਮੈਨੇਜਮੈਂਟ ਨੀਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਫਿਰਮਵੇਅਰ ਅਤੇ ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਰਾਹੀਂ ਅੱਪਡੇਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ—ਨਵੇਂ ਨਿਰਦੇਸ਼, ਉਹੀ ਡਿਵਾਈਸ।
Python ਅਤੇ JavaScript ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ interpreter ਜਾਂ virtual machine ਰਾਹੀਂ ਚਲਦੀਆਂ ਹਨ। ਸੀਧਾ CPU ਤੁਹਾਡੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਨਹੀਂ ਚਲਾਉਂਦਾ; ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ ਰੂਪ (bytecode ਜਾਂ ਅੰਦਰੂਨੀ ਨਿਰਦੇਸ਼) ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਦਮ-ਦਰ-ਕਦਮ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। Java ਦਾ JVM, .NET, WebAssembly ਰੰタイਮ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ JavaScript ਇੰਜਣ ਸਾਰੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹਨ: ਨਿਰਦੇਸ਼ ਇਕ ਡਾਟਾ-ਸੰਰਚਨਾ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਮਸ਼ੀਨ ਲੋਡ ਅਤੇ ਚਲਾ ਸਕਦੀ ਹੈ।
ਕਿਉਂਕਿ ਨਿਰਦੇਸ਼ “ਕੇਵਲ” ਜਾਣਕਾਰੀ ਹੁੰਦੇ ਹਨ, ਹਮਲਾਵਰ ਅਕਸਰ ਅਣ-ਭਰੋਸੇਯੋਗ ਡਾਟਾ ਨੂੰ ਚਲਾਉਣਯੋਗ ਕੋਡ ਵਜੋਂ ਪ੍ਰਵੇਸ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ—ਕੋਡ ਇੰਜੈਕਸ਼ਨ ਇਸ ਦਾ ਕਲਾਸਿਕ ਉਦਾਹਰਨ ਹੈ। ਮੈਮੋਰੀ ਰੋਕਥਾਮ, ਕੋਡ ਸਾਇਨਿੰਗ ਅਤੇ ਨਾਨ-ਐਗਜ਼ਿਕਯੂਟੇਬਲ ਮੈਮੋਰੀ ਖੇਤਰ ਵਰਗੇ ਰੱਖ-ਰਖਾਅ ਇਸ ਤੋਂ ਬਚਾਅ ਲਈ ਹਨ, ਤਾਂ ਜੋ ਅਣ-ਭਰੋਸੇਯੋਗ ਡਾਟਾ ਨੂੰ ਚਲਾਇਆ ਨਾ ਜਾ ਸਕੇ।
ਇਹ ਸਭ ਮੁੜ ਕੇ ਸਟੋਰਡ-ਪ੍ਰੋਗ੍ਰਾਮ ਦੇ ਕੇਂਦਰੀ ਵਾਅਦੇ ਤੇ ਆਉਂਦਾ ਹੈ: ਸਾਫਟਵੇਅਰ ਰਾਹੀਂ ਲਚੀਲਾਪਣ—ਉਹੀ ਹਾਰਡਵੇਅਰ, ਨਵਿਆਂ ਵਿਹਾਰ।
ਜਦ ਤੁਸੀਂ ਕਿਸੇ ਕੰਪਿਊਟਰ ਨੂੰ ਦੇਖ ਰਹੇ ਹੋ ਜਾਂ ਕਿਸੇ ਸਪੇਕ ਨੂੰ ਪੜ੍ਹ ਰਹੇ ਹੋ, ਇਹ ਸਵਾਲ ਮੂਲ ਮਾਡਲ ਕੋਛਣ ਵਿੱਚ ਮਦਦਗਾਰ ਹਨ:
ਜੇ ਤੁਸੀਂ ਹੋਰ ਪੈਠ-ਮਿੱਤਰ ਲੇਖ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਬਲੌਗ ਵੇਖੋ।
ਨੋਟ: ਜੇ ਤੁਸੀਂ ਆਧੁਨਿਕ ਤਰੀਕੇ ਨਾਲ "ਨਿਰਦੇਸ਼" ਨੂੰ ਚਲਾਉਣ ਦੇ ਨਵੇਂ ਤਰੀਕੇ ਅਜ਼ਮਾਉਂਦੇ ਹੋ—ਚਾਹੇ ਕੋਡ ਸਿੱਧਾ ਲਿਖ ਕੇ ਹੋਵੇ ਜਾਂ ਚੈਟ-ਚਲਿੱਤ ਬਣਾਉਣ ਵਾਲੇ ਪਲੇਟਫਾਰਮ ਵਰਤਕੇ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਉਸਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉ। Koder.ai ਵੀ ਇੱਕ earn-credits ਪ੍ਰੋਗਰਾਮ ਦਿੰਦਾ ਹੈ ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਰੈਫ਼ਰਲ ਲਈ, ਜੋ ਅਧਿਐਨ ਅਤੇ ਟਿਊਟੋਰੀਅਲ ਲਈ ਫੰਡ ਪ੍ਰਦਾਨ ਕਰਨ ਦਾ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ।
A stored-program computer keeps program instructions in the same internal memory used to hold the data those instructions operate on. To change tasks, you load a different set of instructions into memory instead of rewiring or reconfiguring the machine’s hardware.
Before stored programs, many machines were effectively “programmed” with plugboards, patch cables, and switch settings. Changing the sequence of operations could mean hours or days of rewiring and retesting, and a single wrong connection could introduce hard-to-find errors.
In this context, “memory” means the computer’s fast working storage (most like modern RAM) that the CPU can read and write constantly while running. It’s different from long-term storage (like disks/SSDs), which is for keeping programs and files when power is off.
The EDVAC report clearly described the organization where instructions and data share internal memory, along with a useful vocabulary for talking about computer parts (memory, control, arithmetic, input/output). That clarity helped other teams discuss, compare, and build similar systems more quickly.
His name stuck largely because his descriptions were widely circulated and easy to reference, not because he was the only contributor. The stored-program approach emerged from a broader community (engineers, mathematicians, and early programmers) working on related problems at the same time.
“Von Neumann architecture” usually refers to a model with:
It’s a convenient teaching label for the stored-program organization, not a claim about a single historical machine or a sole inventor.
In a von Neumann-style design, instructions and data share one memory (often one main path to the CPU). In a Harvard-style design, instruction storage is separated from data storage (often with separate paths).
Many modern systems blend the two—e.g., one memory model for software, but separate instruction/data caches internally.
The “von Neumann bottleneck” is the performance limit that can happen when the CPU and memory share a constrained path for moving both instructions and data. Common mitigations include caches, prefetching, and parallelism (like multiple cores), which reduce waiting but don’t eliminate the underlying constraint.
Because programs are just information that can be loaded into memory, you can update behavior by changing software instead of changing chips. That’s why the same phone or laptop can run many apps, and why firmware/OS updates can add features without redesigning hardware.
Since instructions are represented as data in memory, attackers sometimes try to trick systems into treating untrusted data as executable code (e.g., code injection). Modern defenses include memory protection (non-executable regions), code signing, and other controls that separate “data you may read” from “code you may run.”