<div dir="ltr">I second the motion!<div><br></div><div>Or use git or any other version control system.</div><div><br></div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 6:28 PM, Magnus Karlsson <span dir="ltr"><<a href="mailto:magnus@saanlima.com" target="_blank">magnus@saanlima.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting.<br>
<br>
One concern I have here is the complete lack of revision control for the<br>
RISC5 Verilog source files. When I started to play with Oberon for<br>
Pipistrello I grabbed the Verilog source files from<br>
<a href="http://www.projectoberon.com" rel="noreferrer" target="_blank">http://www.projectoberon.com</a> in a file called RISC5Verilog.zip, where<br>
all included files were dated Feb 15, 2014. Later someone brought to my<br>
attention that I wasn't using "the latest version" and sure enough the<br>
file RISC5Verilog.zip was now different - three files now had a time<br>
stamp of March 3, 2015 (RISC5Top.v, RISC5.v and RISC5.ucf) - without any<br>
indication on the web site that the zip file had been updated. A quick<br>
diff showed that a GPIO port had been added (which was not a big concern<br>
for me) as well as changes to the core RISC5 processor with no<br>
documentation or even a comment at all regarding the reason for the<br>
changes (big concern for me, bug fixes or added functionallity?).<br>
<br>
I think a bare minimum here is to include a date in the name of the zip<br>
file (e.g. call it RISC5Verilop_ 20150303.zip) so that it's clear to all<br>
what version they look at. I think it's also bare minimum to have a<br>
short revision history at the top of each source file that dates the<br>
change and gives a reason for the change.<br>
<br>
Cheers,<br>
Magnus<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 8/26/2015 6:49 AM, Paul Reed wrote:<br>
> Hi David,<br>
><br>
>> Just to 'chime in' with what Wojtek is saying. If you look at the<br>
>> Verilog code, there is a GPIO In and GPIO out port. Those are not<br>
>> mentioned in Ch. 17 that is available on the Project Oberon page.<br>
> That's the exception which proves the rule. Prof. Wirth added a couple of<br>
> IOs while he was experimenting with programming PIC chips for a project<br>
> (see his section on PICL), and I persuaded him to make it an 8-bit GPIO<br>
> port. So my bad! :) Consider it experimental. All the rest is<br>
> documented, right?<br>
><br>
> Cheers,<br>
> Paul<br>
><br>
><br>
><br>
> --<br>
> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
><br>
<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>