On 2017-10-14 01:05, Steve D'Aprano <steve+pyt...@pearwood.info> wrote:
> On Sat, 14 Oct 2017 07:15 am, Peter J. Holzer wrote:
>> On 2017-10-13 15:11, alister <alister.w...@ntlworld.com> wrote:
>>> On Sat, 14 Oct 2017 01:48:44 +1300, Gregory Ewing wrote:
>>>> Steve D'Aprano wrote:
>>>>> I wasn't questioning where the data came from, but how the compiler can
>>>>> write to READ ONLY MEMORY which might not even be in the same continent
>>>>> as the compiler that generated the code.
>>>>
>>>> I thought it would be fairly obvious that by "put it in read-only
>>>> memory" I meant "arrange for it to be in a location that is read-only at
>>>> run time". Obviously it can't be read-only at *compile* time, just as a
>>>> physical ROM can't be read-only at manufacture time.
>>>
>>> oh yes it can
>>> in the past for large quantitys the data in a ROM chip was part of the
>>> chip etching mask (unless you consider a blank silicon wafer to be
>>> "Programmable" by the etching process)rather than prom which used
>>> programmable fuses or prom which could be erased by UV light (assuming
>>> the chip was fitted with a window otherwise it was known as one time
>>> programmable EPROM)
>>
>> He didn't say "programmable". He said that the is "not read-only".
>
> In context, we are talking about a computer program (the compiler) writing
> data to memory.
No, I don't think so. You keep talking about that, even though Gregory
hasn't used those exact words and has since clarfified that he didn't
mean it that way. Y'know, I'm all for writing as carefully und
unambiguously as possible and for discussing questionable wording
(especially in a large forum where many (including me) will have a
different native language), but we all are sloppy in our writing every
now and then and insisting that somebody must have meant X' because they
wrote X doesn't really help and gets boring pretty soon.
Right now I was replying to alister's claim that "yes [ROMs] can [be
read-only at manufacture time]". That doesn't have anything with
compilers. Where the information came from is irrelevant to the question
whether ROMS are read-only during manufacture. Certainly they are not
only read (I don't know if they are read at all, but I guess they are
during quality control), but information is put onto them. I think that
this process can be called "writing" (It's a lot closer to what has been
called "writing" for the last few millenia than what happenes to a RAM
chip during "writing"), but even that is a red herring as the word
"write" wasn't actually used (only "read").
> Your example of writing on paper is a good one, but it argues *against* your
> position, not for it. If you compile some code, then take a hex dump and
> print it out:
>
> gcc program.c
> xxd a.out | lp
>
> would you describe the process as "the compiler writes to the piece of paper"?
No, but the printer does. And that means that the paper is not
read-only. Which was the point of the exchange between Gregory and
alister. The compiler isn't in the game any more.
But there is a difference between printing the hex dump of the output of
the compiler and loading it into memory to be executed. The latter is
the intended purpose of the file. When a compile writes some data into
the ".rodata" section of the file, the intention is that this data
should be read-only at run-time. Therefore I consider the phrasing "the
compiler puts it into read-only memory", while certainly sloppy and not
technically correct, perfectly comprehensible. And I can't find anything
wrong with his revised phrasing "arrange for it to be in a location that
is read-only at run time". That's exactly what the compiler does. That
the compiler doesn't actually have control over what happens to the file
afterwards is immaterial.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
--
https://mail.python.org/mailman/listinfo/python-list
