[colm-users] Hardcoded word_t

[Adrian Thurston]

Great, thanks, just merged it.

On 2018-05-12 05:55, Konstantin Podsvirov wrote:
> Hello again!
> 
> 11.05.2018, 20:11, "Adrian Thurston" <thurston at colm.net>:
>> We'll get this cleaned up eventually. There is nothing about the
>> language design that demands certain sizes for things. It's just a
>> matter of me doing most of my research on a certain platform. It's
>> important to note that colm is still a research project. Ragel 7 
>> depends
>> on it now, but that is still also a development release.
>> 
>> Note I've got some changes to colm to push that fix certain issues 
>> that
>> arise on platforms other than the one I work on mostly (amd64 ubuntu
>> 16.04). Coming soon.
> 
> I have solution :-)
> 
> Today after latest changes in `master` branch I can compile `coml`
> with MinGW-w64 64bit toolchains.
> 
> Your can try changes from `word` branch on my server:
> 
> http://git.podsvirov.pro/?p=dad/fix/colm.git;a=shortlog;h=refs/heads/word
> 
> All changes in one last commit:
> 
> The type word_t declaration
> 
> If sizeof(unsigned long) == sizeof(void *) then word_t is unsigned 
> long.
> Else if sizeof(unsigned long long) == sizeof(void *) then word_t is
> unsigned long long.
> 
> Compilation checked with MSYS2 toolchains via Autotools project and
> with MinGW-w64 toolchains via CMake project.
> 
> http://git.podsvirov.pro/?p=dad/fix/colm.git;a=commitdiff;h=63224902a50c68b3ce4e38827199bae4d50746f3
> 
> Also available via git:
> 
> git clone -b word git://podsvirov.pro/dad/fix/colm.git
> 
> Adrian, please review my changes and apply if posible.
> 
>> On 2018-05-11 05:05, Konstantin Podsvirov wrote:
>>>  03.05.2018, 21:13, "Konstantin Podsvirov" 
>>> <konstantin at podsvirov.pro>:
>>>>>>  20:12, 3 May 2018 г., Adrian Thurston <thurston at colm.net>:
>>>>>>>  Hi Konstantin,
>>>>>>> 
>>>>>>>  code_t is the type used to encode virtual machine instructions.
>>>>>>>  Just
>>>>>>>  need 1 byte for this now.
>>>>>>> 
>>>>>>>  half_t is used mostly for virtual machine instruction arguments. 
>>>>>>> It
>>>>>>>  started out as 2 bytes, but has grown. It might have been made
>>>>>>>  larger
>>>>>>>  than needed at the moment -- haven't looked at that in long 
>>>>>>> time.
>>>>>>> 
>>>>>>>  word_t is the primary type for virtual machine values pushed to 
>>>>>>> the
>>>>>>>  stack and operated on by the VM. The values are either pointers 
>>>>>>> to
>>>>>>>  things or integers. The VM assumes the same size here, so 
>>>>>>> whatever
>>>>>>>  type
>>>>>>>  is used it needs to be the same size as a pointer or there will 
>>>>>>> be
>>>>>>>  some
>>>>>>>  trouble.
>>>>>>> 
>>>>>>>  Admittedly, portability needs to be improved.
>>>>>>  Hi Adrian,
>>>>>>  thank you for the clarification. I think this is enough for
>>>>>>  experiments.
>>> 
>>>  After studying the code, several attempts and experiments, I want to
>>>  say that adding support for 64-bit platforms is not a trivial task.
>>> 
>>>  Unfortunately I do not have the time and energy to solve this issue.
>>> 
>>>>>>>  On 2018-04-30 11:34, Konstantin Podsvirov wrote:
>>>>>>>>   30.04.2018, 18:06, "Adrian Thurston" <thurston at colm.net>:
>>>>>>>>>   Hi, yes would like to have this fixed at some point. Sorry no
>>>>>>>>>  ETA at
>>>>>>>>>   the moment.
>>>>>>>> 
>>>>>>>>   But can you briefly describe what does each type code_t, 
>>>>>>>> word_t,
>>>>>>>>   half_t and what are the requirements in size and made to them.
>>>>>>>> 
>>>>>>>>>   On 2018-04-29 12:53, Konstantin Podsvirov wrote:
>>>>>>>>>>   Hello colm developers... :-)
>>>>>>>>>> 
>>>>>>>>>>   Currently the word_t is hardcoded in src/tree.h file as
>>>>>>>>>>  unsigned long
>>>>>>>>>>   type, bun used to store pointers too.
>>>>>>>>>> 
>>>>>>>>>>   On some platform (for example mingw64) size of the long (4
>>>>>>>>>>  byte) less
>>>>>>>>>>   then size of the void* (8 byte).
>>>>>>>>>> 
>>>>>>>>>>   Previously i add check for this problem in CMake project 
>>>>>>>>>> file,
>>>>>>>>>>  but
>>>>>>>>>>   not provide any solution.
>>>>>>>>>> 
>>>>>>>>>>   What you think about this?
>>>>>>>>>> 
>>>>>>>>>>   --
>>>>>>>>>>   Regards,
>>>>>>>>>>   Konstantin Podsvirov
>>>>>>>>>> 
>>>>>>>>>>   _______________________________________________ colm-users
>>>>>>>>>>  mailing
>>>>>>>>>>   list colm-users at colm.net
>>>>>>>>>>   http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
>>>>>>>>>   ,
>>>>>>>>> 
>>>>>>>>>   _______________________________________________
>>>>>>>>>   colm-users mailing list
>>>>>>>>>   colm-users at colm.net
>>>>>>>>>   http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
>>>>>>>> 
>>>>>>>>   --
>>>>>>>>   Regards,
>>>>>>>>   Konstantin Podsvirov
>>>>>>>> 
>>>>>>>>   _______________________________________________
>>>>>>>>   colm-users mailing list
>>>>>>>>   colm-users at colm.net
>>>>>>>>   http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  colm-users mailing list
>>>>>>>  colm-users at colm.net
>>>>>>>  http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
>>>>>> 
>>>>>>  _______________________________________________
>>>>>> 
>>>>>>  colm-users mailing list
>>>>>>  colm-users at colm.net
>>>>>>  http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
>>>>> 
>>>>>  Regards,
>>>>>  Konstantin Podsvirov
>>> 
>>>  _______________________________________________
>>>  colm-users mailing list
>>>  colm-users at colm.net
>>>  http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
>> 
>> _______________________________________________
>> colm-users mailing list
>> colm-users at colm.net
>> http://www.colm.net/cgi-bin/mailman/listinfo/colm-users
> 
> Regards,
> Konstantin Podsvirov
> 
> 
> _______________________________________________
> colm-users mailing list
> colm-users at colm.net
> http://www.colm.net/cgi-bin/mailman/listinfo/colm-users