search for: gadts

Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux leaves long mode in kernel_jump assembly routine does not follow AMD64 specifications. More precisely: 1. After setting a new GADT, `cs` has to be refresh by doing a long jump, but it is not 2. Other segments have to be updated, but they are not 3. Disabling paging has to be done before disabling long mode, but the

> On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2.

> Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other segments have to be updated, but they are not > 3. Disabling paging has to be done before

>>> > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other segments have to be updated, but they are not > 3. Disabling paging has to be

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

2015-08-23 20:09 UTC+02:00, Gene Cumm via Syslinux <syslinux at zytor.com>: > On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux > <syslinux at zytor.com> wrote: >> Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux >> leaves long mode in kernel_jump assembly routine does not follow AMD64 >> specifications. More precisely: >> 1.

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

...og.janestreet.com/pattern-matching-and-exception-handling-unite/) - Record fields and variant constructors can have the same name and the compiler sorts out the right struct/type intelligently. (OCaml >= 4.01, http://www.lexifi.com/blog/type-based-selection-label-and-constructors) - GADTs and first class modules allow more "sophisticated" used of modules, although I tend to think that these will just make the code more confusing so I would push back on people trying to use if they were being too clever. (OCaml >= 3.12 and especially >= 4.00 https://forge...

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

...type int_op = [ `IAdd | ... ] type float_op = [ `FAdd | ... ] type bool_op = [ `ILe of int_op * int_op | ... ] type t = [ int_op | float_op | bool_op | ... ] end Now you have int_op and bool_op as subtypes of Op.t. Note that neither of these approaches can be as expressive as using GADTs which, I assume, is what the Haskellers have done. On the other hand, this will probably catch errors that people don't make anyway (hence my opening question). There is an overhead in building these intermediate data structures but I expect it will be insignificant. You also have the adva...

I was talking to Gordon on #llvm earlier, and he challenged me with coming up with a way to improve the ocaml binding's type safety. We can't go letting haskell beat us now, can we? I think I got an easy solution with phantom types. For those who don't know what the problem is, the ocaml bindings share one type between whole class branches (like values). This means we need to downcast