Java C and Java questions that I asked my teacher

[Mark44]

"Data" and "Code" are interchangeable at the hardware level (that is, the hardware that moves information to/from the RAM/CPU does not no or care whether it is code or date.

Depending on the process, this might not be true. Some processors will not allow the execution of code that appears in a data section.

BUT ... your terminology is somewhat misleading. It should say CODE, not data, where I have bolded it.

I'm not sure what you mean here. Assembly language IS machine language.

That is not true. Assembly language is human readable (somewhat), while machine code is straight binary code. An assembler translates human readable assembly code to object code, and a linker brings in any other needed object code to create an executable.

Assembly language adheres to the "principle of one to one correspondence", which says each assembly language instruction is exactly one machine language instruction. That is essentially never true for compilers and is absolutely never true for interpreters.

It IS possible to interact with computers without any assemblers / compilers / interpreters, etc, although that is NOT true of standard computers today.

In the 1960's I had a minicomputer [well, *I* didn't have the computer ... NASA did and I worked there]. Every morning when I came in, I had to load 10 instructions into the computer. These instructions made up a "bootstrap loader" which had just enough intelligence to load a large block of code from a magnetic tape into RAM and turn over execution to it. That block of code was a full loader, and then loaded the rest of the operating system [which was VERY primitive, and of my own design].

The WAY that I loaded the 10 instructions was by way of 16 data switches and some control switches on the front panel of the minicomputer [which, by the way, was about the size of a refrigerator]. I would put in each of the 10 instructions as 16 bits in the data switches and then hit the control switch that said "load this to memory and increment the memory pointer", and I would do that for all 10. So basically, *I* was the "assembler" and my fingers combined with the switches to be the "loader".

 

[pairofstrings]

Okay. Thanks for making it clear for me. I somehow managed to realize that answers to my questions lies in studying computer architecture and doing embedded system programming.

Please observe the first figure in post # 32

Please see the code.

#include <stdio.h>
void main{
int a = 5;
const int b = 10;
printf("%d %d", a , b);
*/b = b + a ;
printf("%d", b);*/
}

I asked my teacher one question on this
I said: So, when compiler encounters the 'const' keyword, a memory location is allocated in the ROM and the corresponding data value is assigned to the variable. And a .exe file is generated and stored in HDD and now if I want to run this generated .exe file, I need to double click the .exe file and the Loader loads the .exe file into the RAM and ROM is not used here at all. So, ROM is not used when Loader loads the .exe file into the RAM and ROM is only used during compilation to assign data values to the variable.

Teacher said: Yes.

I thought maybe engineers have compromised with the name, meaning and function of the ROM and instead of having a non erasable memory inside the ROM, the engineers might have constructed an erasable memory adjacent to non-erasable memory. No big deal. Then erasable memory will have a laser mechanism that will help in delete the already present data inside the erasable memory once the laser is switched on. And compilers are programmed to switch this laser on and off. This is totally achievable. But I thought this is good as long as this process is fast enough. I mean, sending data to a different memory(ROM), especially erasable memory here and with laser mechanism to delete data that is already present in it is quite good but much time consuming and we need faster mechanism. But, I didn't bother to ask him this question about how we are going to deal with time consumption problem when we use this concept of using different memory(ROM) to temporarily store/assign data values to the 'const' declared variables inside erasable memory with laser mechanism to delete already present data and which is built adjacent to non-erasable memory inside ROM. Like in the figure below. Please see.

My thoughts on what can be right: I think that if I don't use ROM at all in assigning data values to the variables that are declared as 'const', then I must program the compiler to do all the assigning work while the data is in the RAM. That way, I won't have to use any other special memory for assignment of data values to the variables that are declared as 'const', or any other variables and data values. I think, I will come across all of these concepts when I try to understand the development/programming of Operating system and compilers.

There is another thing that want to know about the system that was discussed in the last paragraph of post # 27

I have great respect for people who worked/work at the highest level of technology. One of my priorities is knowing the initial plans of something that these people worked on. For instance, if Johann Carl Friedrich Gauss and the person who invented exponential function told us the initial plans on how they got the initial idea that helped them to come up with their beautiful creations of Gauss function and exponential function, It would have been a great thing today.

So, please take a look at this scenario:

It's 1960s and you came into your office and you started working on your system and you were flipping switches and observing the outcome on you console and then you realized that there is a brand new Intel computer from 2010 A.D sitting on your desk. And you opened the cabin of PC and figured out exactly what each hardware is doing in about an hour, except one thing, that is Hard Drive! Now, you thought 'it's no big deal, let me use my switches to feed data into this new Intel computer from 2010 A.D' and you replaced the HardDrive with the Switches mechanism. Switches are now connected to RAM and RAM is connected to Processor. Processor is connected to the consoles.

I did not bother to draw ROM and Graphics card. Did they exist back in 1960s?

My question is: If you set up a system like that described in the above scenario, I think the system is only designed to calculate the performance of the processor. If I speak a little technically, you knew exactly what voltage and electrical energy is required to make the system work.
I have no idea what "bootstrap loader" is.
Your answer will help me find why exactly switches were used in your creation. I find this very elegant to use switches to tell the processor to do what you want the system to do. That way you can have ultimate control over the processes of the machine. As you mentioned in post# 27 that machine language is same as Assembly language. I want to make myself clear about what I meant when I wrote "(not Assembly language)" in my post# 26 . So that you can tell me where I was wrong.

This is what I thought about the difference between Machine language and Assembly language:

I thought when I am dealing with machine language I am only dealing with 0s and 1s. So, if I want to use machine language to do complicated programming then while I am programming I am suppose to have an interface in which I can write 0's and 1's which represents my actual program and then directly feed it to the processor of the system. I can make this portable my using a memory device and burning all these 0s and 1s on this memory device that I wrote using machine language on an interface. I will attach this memory to my system. So, that when I switch on my system the program is runnable.

In assembly language I will be using mnemonics like ADD, MOV etcetra, instead of using 0s and 1s. As you said, that each machine code instruction is same as each assembly code instruction I am feeling little relieved because I intend to use a language that will help me in interacting with the components at the lowest level possible. So, Assembly language is good for that, I think. Your thoughts please.

So, please comment on my reasoning s and help me find wrong things in this post.
I have another question related to HDD and assembly language and about the mechanism that reads the bits from the HDD, in my coming post.

 

[rcgldr]

I somehow managed to realize that answers to my questions lies in studying computer architecture and doing embedded system programming. ... rom

You're still confusing when things happen. In most cases of embedded system programming, the compiling is done on another computer, perhaps a standard PC. The ROM on the PC is not used during this process. Most programmable devices use EEPROM (electronically erasable programmable rom) to store some or all of the code. In the case of a hard drive, some of the code could be stored on hidden sectors on the hard drive. For most devices, there is usually a small rom (you can call this a "bootstrap" loader) with just enough functionality to download a program and run it. The downloaded program contains code to program the EEPROM and the image of the program to be programmed into the EEPROM.

For embedded programing there's an extra step after the linker, this is the normal sequence:

compile source files to produce object files
link those object files and object files from libraries to produce exe files.
use a tool to convert the exe into an image file appropriate for the embedded system.

Getting back to how "const" is implemented, it could be ignored by a compiler in terms of output and only used to check for source code errors. The classic standard for a program image is:

code
initialized data and where it should be moved to
address and length of data to be zeroed out

At boot time, the code moves the initialized data into RAM, then zeroes out some more RAM, and then setup the stack (or stacks for multi-tasking system), and starts up. "const" data may end up in RAM depending on the architecture of the CPU.

loading in bootstrap programs via switches

Old computers use core memory, which retains data even when power is off, so some of the older mini-computer systems required that the operator manually toggle in the binary data that represented the code and data for a small "bootstrap" program if the core memory got corrupted. When computers switched to using ram, most of them used rom or prom for the "bootstrap" program. The "bootstrap" program would then load in a program from some other device on the computer (punched card, paper tape, magnetic tape, disk).

 

[AlephZero]

Getting back to how "const" is implemented, it could be ignored by a compiler in terms of output and only used to check for source code errors.

Not to mention declaring a variable "const volatile". Yup, you can do that in C, and it really does have a well-defined meaning